5 ms·

Just tried a quick test cluster - Identifies as PG 16.5 No views/triggers/sequences No foreign key constraints No extensions No NOTIFY ("ERROR: Func

by e1g 2y ago

Just tried a quick test cluster - Identifies as PG 16.5 No views/triggers/sequences No foreign key constraints No extensions No NOTIFY ("ERROR: Function pg_notify not supported") No nested transactions No json(b) Unsupported PG features are now online https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-postgresql-compatibility-unsupported-features.html https://docs.aws.amazon.com/aurora-dsql/latest/userguide/wor...

acedTrex 2y ago
I feel like no FKs and no jsonb is really burying the lede there lol
shayonj 2y ago
oof! that's rough. I was also not particularly impressed with "limitless". Esp. because you can't have partitions on the postgres limitless offering.
craigkerstiens 2y ago
It feels very disingenuous to say "Postgres compatible" and have this as a missing feature set. I'm sure they'd quickly argue it's wire compatibility, but even then it's a slippery slope and wire compatible is left open to however the person wants to interpret it. There is no 'standard' or 'spec' for what makes something Postgres wire compatible. This feels like a strong overreach on the marketing front to leverage the love people have for Postgres to help boost what they've built. That is not to say there isn't hard and quality engineering in here, but slapping Postgres compatible on it feels lazy at best.
- benesch 2y ago
  > I'm sure they'd quickly argue it's wire compatibility, but even then it's a slippery slope and wire compatible is left open to however the person wants to interpret it. I actually think that they'd argue they intend to close the feature gap for full Postgres semantics over time. Indeed their marketing was a bit wishful, but on Bluesky, Marc Brooker (one of the developers on the project) said they reused the parser, planner, and optimizer from Postgres: https://bsky.app/profile/marcbrooker.bsky.social/post/3lcghjbvyx22n https://bsky.app/profile/marcbrooker.bsky.social/post/3lcghj... That means they actually have a very good shot at approaching reasonably full Postgres compatibility (at a SQL semantics level, not just at the wire protocol level) over time.
paulddraper 2y ago
Yeah, this is another DocumentDB. They'd save space by listing the supported features. It's not useless, but no existing application would run on it. > Unsupported objects > * Databases - Aurora DSQL supports only one database per cluster at this time. > * Views > * Temporary Tables > * Triggers > * Types > * Tablespaces > * UDFs / Functions other than functions using language = SQL > Unsupported constraints > Foreign keys > Exclusion constraints > Limitations > ... > A transaction cannot modify more than 10,000 rows If you want a distributed PostgreSQL-lookalike, look at CockroachDB.
gigatexal 2y ago
Epic fail then. Wow. That’s DOA.
refset 2y ago
> Aurora DSQL isolation level is equivalent to PostgreSQL Repeatable Read. So it lacks Serializable isolation also, but I guess that's the secret to how it "offers the fastest distributed SQL reads and writes".
- Spivak 2y ago
  DynamoDB with the limitations thereof but with a SQL like frontend so it works with slightly modified existing tooling isn't totally without value.
  - refset 2y ago
    Agreed, but it seems likely that people will casually pick this up instead of actual Postgres without fully appreciating the potential for consistency issues. I'd feel happier if AWS marketing applied your description of the value proposition - 'DynamoSQL'.
bobnamob 2y ago
https://docs.aws.amazon.com/aurora-dsql/latest/userguide/CHAP_quotas.html https://docs.aws.amazon.com/aurora-dsql/latest/userguide/CHA... The quotas page is always the most interesting for any aws service. 10Mb transaction size and 5min transaction duration limits are interesting limitations that kill any "everything lives in the db" notions that one might have. A fully transactional, scalable, distributed data store + queue + db + data stream with triggers is my endgame Also, the 128mb limit on transaction temporary storage seems _very_ limiting for big ol' analytic queries
- karmasimida 2y ago
  Do you really need transaction on analytic queries though? What are the use case for such transactions
  - xuancanh 2y ago
    The limit is for query operations, not just transactions.
jcmfernandes 2y ago
> No foreign key constraints Wat?
- sgarland 2y ago
  You say this as though the kind of people interested in a serverless distributed SQL product know what FK Constraints are, let alone have interest in using them.
  - dalyons 2y ago
    This but unironically - if I’m in the market for a geo distributed hyper scale DB, I genuinely and sincerely have no interest in foreign key constraints. They are pretty much useless, if not actively harmful, at scale.
    - sgarland 2y ago
      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 requires much more diligence from devs, and I have yet to see it implemented well anywhere. Until a single DB instance is serving well in excess of 100K QPS, I wouldn’t be concerned with the impact of FK constraints. Let RDBMS do what it’s good at – keeping your data safe.
      - dalyons 2y ago
        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 system boundaries. They could be vendor systems too, not even just your own services. - soft deletes. you rarely hard delete root objects, so you dont need the FK constraint to protect those dangling refs - eventual consistentency/idempotency - you end up creating data in different systems as part of a workflow (eg signup), and you have to tolerate partial creation for resiliency. - some sort of ORM or sql framework that makes it very difficult to create a leaf row with an invalid FK parent pointer. So in a fundamentally distributed large scale tech ecosystem, FK constraints end up protecting against.... not much. Ive worked at three large scale (10m+ users) companies which all ended up deleting all their FK constraints. And... nothing happened, nothing ever went wrong due to their absence. Its theoretical protection, not practically needed IMHO.
ralusek 2y ago
what index types does it support?
_qxag 2y ago
So it’s basically a CQL/Cassandra alternative. It’s interesting there’s also no comparison page to Cassandra or Amazon Keyspaces. I also now don’t get why they are emphasizing PostgreSQL here when they should be emphasizing CQL compatibility. Being compatible with Postgres wire protocol but not being relational is strange.
- dalyons 2y ago
  What? Cassandra is a very different technology semantically. From data design to consistency models, to transactions, it’s entirely different, don’t know how you drew this conclusion.
  - xuancanh 2y ago
    My guess is from the customer's perspective, DSQL seems to have too many limitations, making it feel more like an enhanced version of a NoSQL database with SQL semantics, ACID transactions, and multi-region capabilities rather than a truly distributed version of a relational database. It seems the DSQL team doesn't fully understand why relational databases remain widely popular today. What makes them great is their flexibility, which lets them handle all kinds of use cases and adapt as things change. But all the limits on transaction size, column size, etc.., and too many missing capabilities pretty much take away all the big advantages relational databases usually offer.
ssahoo 2y ago
Where does it say jsonb is not supported?
garyclarke27 2y ago
How can they ship a database without views? The mind boggles.
deleted 2y ago
[deleted]

by e1g 2y ago

acedTrex 2y ago

I feel like no FKs and no jsonb is really burying the lede there lol

shayonj 2y ago

oof! that's rough. I was also not particularly impressed with "limitless". Esp. because you can't have partitions on the postgres limitless offering.

craigkerstiens 2y ago

It feels very disingenuous to say "Postgres compatible" and have this as a missing feature set. I'm sure they'd quickly argue it's wire compatibility, but even then it's a slippery slope and wire compatible is left open to however the person wants to interpret it. There is no 'standard' or 'spec' for what makes something Postgres wire compatible. This feels like a strong overreach on the marketing front to leverage the love people have for Postgres to help boost what they've built. That is not to say there isn't hard and quality engineering in here, but slapping Postgres compatible on it feels lazy at best.

benesch 2y ago
> I'm sure they'd quickly argue it's wire compatibility, but even then it's a slippery slope and wire compatible is left open to however the person wants to interpret it. I actually think that they'd argue they intend to close the feature gap for full Postgres semantics over time. Indeed their marketing was a bit wishful, but on Bluesky, Marc Brooker (one of the developers on the project) said they reused the parser, planner, and optimizer from Postgres: https://bsky.app/profile/marcbrooker.bsky.social/post/3lcghjbvyx22n https://bsky.app/profile/marcbrooker.bsky.social/post/3lcghj... That means they actually have a very good shot at approaching reasonably full Postgres compatibility (at a SQL semantics level, not just at the wire protocol level) over time.

paulddraper 2y ago

Yeah, this is another DocumentDB. They'd save space by listing the supported features. It's not useless, but no existing application would run on it. > Unsupported objects > * Databases - Aurora DSQL supports only one database per cluster at this time. > * Views > * Temporary Tables > * Triggers > * Types > * Tablespaces > * UDFs / Functions other than functions using language = SQL > Unsupported constraints > Foreign keys > Exclusion constraints > Limitations > ... > A transaction cannot modify more than 10,000 rows If you want a distributed PostgreSQL-lookalike, look at CockroachDB.

gigatexal 2y ago

Epic fail then. Wow. That’s DOA.

refset 2y ago

> Aurora DSQL isolation level is equivalent to PostgreSQL Repeatable Read. So it lacks Serializable isolation also, but I guess that's the secret to how it "offers the fastest distributed SQL reads and writes".

Spivak 2y ago
DynamoDB with the limitations thereof but with a SQL like frontend so it works with slightly modified existing tooling isn't totally without value.
- refset 2y ago
  Agreed, but it seems likely that people will casually pick this up instead of actual Postgres without fully appreciating the potential for consistency issues. I'd feel happier if AWS marketing applied your description of the value proposition - 'DynamoSQL'.

bobnamob 2y ago

https://docs.aws.amazon.com/aurora-dsql/latest/userguide/CHAP_quotas.html https://docs.aws.amazon.com/aurora-dsql/latest/userguide/CHA... The quotas page is always the most interesting for any aws service. 10Mb transaction size and 5min transaction duration limits are interesting limitations that kill any "everything lives in the db" notions that one might have. A fully transactional, scalable, distributed data store + queue + db + data stream with triggers is my endgame Also, the 128mb limit on transaction temporary storage seems _very_ limiting for big ol' analytic queries

karmasimida 2y ago
Do you really need transaction on analytic queries though? What are the use case for such transactions
- xuancanh 2y ago
  The limit is for query operations, not just transactions.

jcmfernandes 2y ago

> No foreign key constraints Wat?

sgarland 2y ago
You say this as though the kind of people interested in a serverless distributed SQL product know what FK Constraints are, let alone have interest in using them.
- dalyons 2y ago
  This but unironically - if I’m in the market for a geo distributed hyper scale DB, I genuinely and sincerely have no interest in foreign key constraints. They are pretty much useless, if not actively harmful, at scale.
  - sgarland 2y ago
    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 requires much more diligence from devs, and I have yet to see it implemented well anywhere. Until a single DB instance is serving well in excess of 100K QPS, I wouldn’t be concerned with the impact of FK constraints. Let RDBMS do what it’s good at – keeping your data safe.
    - dalyons 2y ago
      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 system boundaries. They could be vendor systems too, not even just your own services. - soft deletes. you rarely hard delete root objects, so you dont need the FK constraint to protect those dangling refs - eventual consistentency/idempotency - you end up creating data in different systems as part of a workflow (eg signup), and you have to tolerate partial creation for resiliency. - some sort of ORM or sql framework that makes it very difficult to create a leaf row with an invalid FK parent pointer. So in a fundamentally distributed large scale tech ecosystem, FK constraints end up protecting against.... not much. Ive worked at three large scale (10m+ users) companies which all ended up deleting all their FK constraints. And... nothing happened, nothing ever went wrong due to their absence. Its theoretical protection, not practically needed IMHO.

ralusek 2y ago

what index types does it support?

_qxag 2y ago

So it’s basically a CQL/Cassandra alternative. It’s interesting there’s also no comparison page to Cassandra or Amazon Keyspaces. I also now don’t get why they are emphasizing PostgreSQL here when they should be emphasizing CQL compatibility. Being compatible with Postgres wire protocol but not being relational is strange.

dalyons 2y ago
What? Cassandra is a very different technology semantically. From data design to consistency models, to transactions, it’s entirely different, don’t know how you drew this conclusion.
- xuancanh 2y ago
  My guess is from the customer's perspective, DSQL seems to have too many limitations, making it feel more like an enhanced version of a NoSQL database with SQL semantics, ACID transactions, and multi-region capabilities rather than a truly distributed version of a relational database. It seems the DSQL team doesn't fully understand why relational databases remain widely popular today. What makes them great is their flexibility, which lets them handle all kinds of use cases and adapt as things change. But all the limits on transaction size, column size, etc.., and too many missing capabilities pretty much take away all the big advantages relational databases usually offer.

ssahoo 2y ago

Where does it say jsonb is not supported?

garyclarke27 2y ago

How can they ship a database without views? The mind boggles.

deleted 2y ago

[deleted]