141–146 of 146 posts
Earlier quoted context omitted.
Seems like it's mostly AWS' answer to Cloudflare D2, but using Postgres as the frame of reference instead of sqlite. (I'm not really sure what to call Postgres in this situation since it's so limited it's clearly not any full version of Postgres in any respect. Postgres-ish)
> Cloudflare D2 Not that it matters but it's D1 but I noticed people sometimes call it D2, maybe by analogy with R2.
Earlier quoted context omitted.
AWS tends to prioritize performance and scalability over functionality, which is reflected in the design of DynamoDB, SimpleDB, and now DSQL. I'm also not a big fan of this style. It doesn't give customers the flexibility to choose their own trade-offs like Spanner does and assumes that customers can't make these kinds of decisions on their own.
Oh yeah nowadays AWS believes more choices more footguns
Earlier quoted context omitted.
> Except for some basic wire compatibility with the postgres protocol, I'd hardly call this a "database", and more a key-value store. Hopefully that keeps the pricing reasonable. :) But seriously, for a smaller CRUD app, this could be sufficient, even "magical," if the price is right. For my part though, the lack of multiple databases per cluster puts multi-tenant systems completely off the table. Now that you mentio…
But a smaller CRUD app wouldn't need "virtually unlimited scale". I'm very curious what their target audience is.
Having it be Postgres compatible is the big selling point.
Who else would use it? Not sure, gaming perhaps?
Earlier quoted context omitted.
I'm also on Neon. Seems like the primary benefit of this would be multi-region support, which Neon doesn't have. But I do wonder if multi-AZ is actually just enough, has there ever really been a time when all AZs have gone down?
(neon employee) we have multi-region disaster recovery and replicas coming in 2025. Switch over time will be greater than this active-active system but the overall latency for Neon should be much less on a consistent basis.
I find it to be super limited, and I'm sort of struggling to see the point given all these constraints. No temporary tables, no foreign keys, no views, no more than 10k rows in a transaction. Except for some basic wire compatibility with the postgres protocol, I'd hardly call this a "database", and more a key-value store. https://docs.aws.amazon.com/aurora-dsql/latest/userguide/wor...
Despite this number of limitations, I imagine that it's still far more usable from an application than DynamoDB for many use-cases. Adding Jsonb support would make it even more competitive for some.
I do not want to denormalize my data model, i do not have a high performance usecase, I simply want infrastructure that scales with usage (down to 0) and a flexible normalized model I can build more on top of easily.
DDB is great and all until you're asked to add 3 filters and orderby feature and suddenly you're adding elastic search to your project
Earlier quoted context omitted.
Disagree heavily that they’re useless at scale. Both PlanetScale and Citus support them (though the former doesn’t support it on sharded DBs yet), as well as TiDB (alpha), and Yugabyte. As far as performance hits go, I guarantee I could find a half dozen other, larger problems that would have a bigger impact than disabling FK constraints. It is of course possible to maintain referential integrity without them, but it…
I didnt necessarily mean scale as req/sec, although that is a factor, more system complexity & num of engineers. In a large enough companies tech ecosystem you tend to evolve a few characteristics: - many data stores. even if you're not doing microservices persay, you're almost certainly going to end up with different domains/buis units/systems having their own data stores. FK constraints obviously dont work across s…
Not to their full extent, but they can still be used. At the simplest level, it is of course entirely possible to give different services their own schema in a given database, and FK constraints are supported across schemata in both MySQL and Postgres. Vertical scaling can take you enormously far with properly architected schemata and queries.
A more flexible, but still easy to reason about way to accomplish this is to have local versions of certain tables in each DB. This can be manually implemented (though this is not an easy problem to solve, for a variety of reasons), or by using something like Citus [0], which accomplishes this using 2PC. This is of course slower, but if your data model is carefully designed, it can be managed.
> soft deletes.
Sure, but now you have a new problem - needing to add a `is_deleted` or `deleted_at` column to a bunch of tables, and indexing that column on every table. In Postgres you might get away with this by using `DEFAULT [FALSE, NULL]` (respectively), and then creating a partial index with `...WHERE IS NOT [FALSE, NULL]`; that way the index size stays reasonable, and the cardinality isn't as horrible (well, it is for bools, but since you're only using it as a filter, it can work OK). Also, of course, you have to include this predicate in most queries.
> Its theoretical protection, not practically needed IMHO.
Different subjective experiences, of course, but IME it very much saves you time and headaches.