Who goes out of their way to “star” a GitHub repo, and what does that even mean? Is it a “like” button, a tip jar, or a bookmark? Does this bare any relationship to the importance, quality, novelty, trustworthiness, or any other property of the repo other than number of stars?
We did this with MotherDuck, and without introducing a new language. Every tenant has their own isolated storage and compute, so it’s trivial to grant internal users access to specific tenants as needed. DuckDB’s SQL dialect is mostly just Postgres’ with some nice ergonomic additions and a host of extra functionality.
This is explicitly not the problem they are trying to solve. In a single tenant database you don’t have to by definition worry about multi tenant databases
I guess the question then becomes, what problem does a multi-tenancy setup solve that an isolated database setup doesn't? Are they really not solving the same problem for a user perspective, or is it only from their own engineering perspective? And how do those decisions ultimately impact the product they can surface to users?
Off the top of my head, managing 100 different database instances takes a lot more work from the business standpoint than managing 1 database with 100 users.
The article also mentioned that they isolate by project_id. That implies one customer (assume a business) can isolate permissions more granulary.
With multi-tenant vs multi-database decision one driver would be the level of legal/compliance/risk/cost/resource drivers around how segregated users really are.
Multi-database is more expensive generally but is a more brain dead guaranteed way to ensure the users are properly segregated, resilient across cloud/database/etc software releases that may regress something in a multi-tenant setup.
Multi-tenant you always run the risk of a software update, misconfiguration or operational error exposing existence of other users / their metadata / their data / their usage / etc. You also have a lot more of a challenge engineering for resource contention.
Agreed, in Multi-tenant, where the user/customer owns the data, I always reach for SQLite first. Each user/customer gets their own SQLite DB. Then you have a common PG/SQLite DB for any common metadata, billing, etc.
That way when a customer leaves or they want a backup copy of their data, it's a rm <customer>.sqlite3 or .backup away.
Sometimes you can't do that for various (almost always non-technical) reason(s), but it's always my 1st choice.
In a system with organizations, projects and advanced user access permissions having separate databases doesn’t full solve the problem. You still need access control inside each tenanted database. It also makes cross-cutting queries impossible which means users can’t query across all their orgs for example.
The DSL approach has other advantages too: like rewriting queries to not expose underlying tables, doing automatic performance optimizations…
I just re-watched Ghost in the Shell SAC Laughing Man last night, and wouldn't mind seeing these things get hacked with the Laughing Man logo replacing any face it was looking at, re-writing signs, etc.
there's always room for another software arms race. the personal area network is not ready and the evolution will be painful and good for someone - us, or them, without regard for what those divisions are, it's going to hurt.
DuckDB had the right idea: just allow some flexibility in the relative order of the `select` and `from` clauses, and make a few other concessions for ergonomics. This then becomes valid:
from events -- table is first, which enables autocomplete
select
count(), -- * is implied, easier to type
customer_id, -- trailing commas allowed everywhere
group by all -- automatically groups by all non-aggregate columns
order by all -- orders rows by all columns in selected order
I get the ease of use - and sometimes use them myself- but implied (or relative) shortcuts are IMO a bad habit that can lead to serious issues that don't manifest as errors.
I do like the from clause first which better matches the underlying relationship algebra!
If you were to rank all of the C compilers in the world and then rank all of the welfare systems in the world, this vibe-coded mess would be at approximately the same rank as the American welfare system. Especially if you extrapolate this narcissistic, hateful kleptocracy out a few more years.
That would require restarting your services to redirect their output. Fine for one-off scripts, but impractical when you have long-running processes and don't want to restart them every time an agent needs to read logs.
With teemux, a persistent MCP server gives multiple AI agents access to logs as needed—without interrupting your development flow.
OK, but it isn't like agents react to flowing logs, they just connect to whatever server and query the past 5 minutes or 2 hours on demand depending on the debugging task at hand without mixing contexts together.
What a dumb metric to focus on.
reply