61–70 of 116 posts
-- Create a todo for "frectonz"
UPDATE people
SET database = execute_sqlite(
database,
$sqlite$INSERT INTO todos VALUES ('solve multitenancy')$sqlite$
WHERE name = 'frectonz';
I think SQLite columns for SQLite would be superior to SQLite’s JSON columns whose operators are a whole ‘nother query language you need to learn and seem comparatively limited.
You may want to use the $$ way to declare strings for your examples. Something like: -- Create a todo for "frectonz" UPDATE people SET database = execute_sqlite( database, $sqlite$INSERT INTO todos VALUES ('solve multitenancy')$sqlite$ ) WHERE name = 'frectonz';
I think SQLite columns for SQLite would be superior to SQLite’s JSON columns whose operators are a whole ‘nother query language you need to learn and seem comparatively limited.
Earlier quoted context omitted.
When your application scales beyond one machine that needs access to the same database, PostgreSQL becomes an obviously better choice than SQLite. Until that point, SQLite is a fine, and honestly underrated choice. DuckDB is another option worth considering.
Should the concept of "machines" really be a concern of the DB layer? SQLite already allows multiple connections, so putting it on a server and adding a program that talks a network protocol and proxies the queries to the DB sounds more logical to me?
Writing a networked application that uses SQLite as a database is perfectly reasonable. You're just making the decision to lift the layer of abstraction that is concerned with machines from the DB to your application, which may or may not be a reasonable thing to do.
Earlier quoted context omitted.
Notion has 100 million users, managing schema-per-tenant at our scale sounds like a complexity nightmare. We have 480+ identical schemas across 100+ Postgres hosts, and that already takes a lot of brainpower & engineering time to manage T_T
> managing schema-per-tenant at our scale sounds like a complexity nightmare. The per-tenant schema could be the tenant's responsibility. Most non-technical users can handle the idea of tables & columns, assuming you leverage UI/UX patterns they are already familiar with.
As long as we never add new features, never need to change how we map UI Postgres DDL, and our users never make any mistakes when they change their tables, it could work without being a complexity nightmare
Yo dawg I heard you liked databases so we put a database in your database.