Does Xata allow multiple "projects" or databases to share the same compute? As in, can you have a xata.medium with 3 databases running on it, or do you have to do run 3x xata.micro (or other size)?
Also, are there a minimum number of nodes required for PayG (not on-prem)?
I had to write off Xata (Now called Xata Lite) in the past due to the complicated pricing/plans while not being sure it did what I needed. But the new pricing is understandable and with Neon's acquisition I want to know my options.
EDIT: I missed this section at the bottom since I was already off reading other parts of the website:
> Are you looking for a simple, serverless, no-frills Postgres hosting for your side project, prototype, non-profit or vibe coded app? Xata Lite offers a generous free tier and per-storage pricing.
> Are you a Startup, Scaleup, or Enterprise that is running Postgres at scale? Then the new Xata Postgres platform brings you all the benefits outlined by this blog post.
Hmm, as much as I hate being lumped in with "vibe coded apps" I think Xata would only want me on Xata Lite. I'm not running Postgres "at scale". I do want a no-frills Postgres hosting but Xata Lite's pricing is annoying and hard to guesstimate.
disclaimer, employee at Neon, another postgres hosting provider
My understanding after looking into it, it seems that Xata+SimplyBlock is expected to use ReadWriteOnce persistent volume access modes. This means the claim can only be bound to one node.
I think this solves the split-brain problem because any new postgres readwrite pods on new nodes will fail to bind the volume claim, but it means there's no high-availability possible in the event the node fails. At least, I think that's how kubernetes handles it - I couldn't find too much explaining the failure modes of persistent volumes, but I don't see many other solutions.
At Neon, we solve this issue by having our storage nodes form a consensus protocol with the postgres node. If a new postgres node comes online, they will both contend for multi-paxos leadership. I assume the loser will crash-backoff to reset the in-memory tables so there's no inconsistency if it tries to reclaim the leadership again and wins. In the normal mode with no split-brain and one leader, multi-paxos has low overhead for WAL committing.
Nice to see the underlying tooling is open source, and BYOC. Still, doubtful I'd trust my complex Pg usage to any of these. I've already worked through most of those problems, and don't have time to vet these much less the budget to pay Xata.
One of my mentees worked with Xata in their app using Prisma and it wasn't great. The need for a second db for the 'shadow' db that prisma needs, and they would throw Out of Memory errors frequently without any significant usage.
The app now moved to Prisma's postgres hosting and it works like a charm, only thing that changed is the db.
I'm so glad I'm not the only person pointing this out every time they're brought up. I don't think I've ever felt the need to name and shame a company before, but this was just an egregiously horrible decision that they tried to smooth over and explain away. I will never have any faith in them whatsoever, due solely to that.
I would say it's primarily testing: either testing schema changes or testing your application changes. Copy-on-Write branches help because you can spin up an environment fast with relevant data from production (anonymized).
nice seeing stuff like this go open source tbh, always makes me pause though - for stuff you’ve already solved and run yourself, you think anything ever convinces you to switch or is it just about trust at that point
Does Xata allow multiple "projects" or databases to share the same compute? As in, can you have a xata.medium with 3 databases running on it, or do you have to do run 3x xata.micro (or other size)?
Also, are there a minimum number of nodes required for PayG (not on-prem)?
I had to write off Xata (Now called Xata Lite) in the past due to the complicated pricing/plans while not being sure it did what I needed. But the new pricing is understandable and with Neon's acquisition I want to know my options.
EDIT: I missed this section at the bottom since I was already off reading other parts of the website:
> Are you looking for a simple, serverless, no-frills Postgres hosting for your side project, prototype, non-profit or vibe coded app? Xata Lite offers a generous free tier and per-storage pricing.
> Are you a Startup, Scaleup, or Enterprise that is running Postgres at scale? Then the new Xata Postgres platform brings you all the benefits outlined by this blog post.
Hmm, as much as I hate being lumped in with "vibe coded apps" I think Xata would only want me on Xata Lite. I'm not running Postgres "at scale". I do want a no-frills Postgres hosting but Xata Lite's pricing is annoying and hard to guesstimate.
> we deploy the Postgres instances on Kubernetes via the CloudNativePG operator.
I'm curious if split brain cases already experienced. At scale, it should be so https://github.com/cloudnative-pg/cloudnative-pg/issues/7407
disclaimer, employee at Neon, another postgres hosting provider
My understanding after looking into it, it seems that Xata+SimplyBlock is expected to use ReadWriteOnce persistent volume access modes. This means the claim can only be bound to one node.
I think this solves the split-brain problem because any new postgres readwrite pods on new nodes will fail to bind the volume claim, but it means there's no high-availability possible in the event the node fails. At least, I think that's how kubernetes handles it - I couldn't find too much explaining the failure modes of persistent volumes, but I don't see many other solutions.
At Neon, we solve this issue by having our storage nodes form a consensus protocol with the postgres node. If a new postgres node comes online, they will both contend for multi-paxos leadership. I assume the loser will crash-backoff to reset the in-memory tables so there's no inconsistency if it tries to reclaim the leadership again and wins. In the normal mode with no split-brain and one leader, multi-paxos has low overhead for WAL committing.
How on earth is reporting a broken consistency promise a "discussion". That is dubious behavior from the project management.
I also don't see any good reasons for this.
Nice to see the underlying tooling is open source, and BYOC. Still, doubtful I'd trust my complex Pg usage to any of these. I've already worked through most of those problems, and don't have time to vet these much less the budget to pay Xata.
> I've already worked through most of those problems…
Have you talked about this anywhere? I (and I assume many other HN folks) would appreciate any detail you'd be willing to share.
One of my mentees worked with Xata in their app using Prisma and it wasn't great. The need for a second db for the 'shadow' db that prisma needs, and they would throw Out of Memory errors frequently without any significant usage.
The app now moved to Prisma's postgres hosting and it works like a charm, only thing that changed is the db.
[Author here] I'm sorry for the bad experience with Xata. If it's still an issue I'd be glad to have a look.
Just to make sure, I suppose this is on the Xata Lite free tier, not on the Postgres at scale platform that this blog post talks about.
Oh yeah that prisma that decided doing joins in memory was a good idea? Yeah def would trust them to run a db hosting platform too
/s
https://github.com/prisma/prisma/discussions/19748
I'm so glad I'm not the only person pointing this out every time they're brought up. I don't think I've ever felt the need to name and shame a company before, but this was just an egregiously horrible decision that they tried to smooth over and explain away. I will never have any faith in them whatsoever, due solely to that.
What's the use case for database branching?
I would say it's primarily testing: either testing schema changes or testing your application changes. Copy-on-Write branches help because you can spin up an environment fast with relevant data from production (anonymized).
If you use a branch per issue you can't have a single staging database. You need multiple databases.
nice seeing stuff like this go open source tbh, always makes me pause though - for stuff you’ve already solved and run yourself, you think anything ever convinces you to switch or is it just about trust at that point
Where do you see this being open source? They have some open source extensions but I don't see their postgres offering being open source.