tudorg

7 ms·

61.
by tudorg 1y ago
Several components are open source as their own projects (see below) which will allow you to reproduce most of the features on top of regular Postgres. But the storage part is not open source. We are considering a simpler implementation of
62.
by tudorg 1y ago
[Disclaimer: I work for Xata] As it happens, we've just launched our new Xata platform ( https://xata.io/ ) which has some of the key Neon features: instant copy-on-write branching and separation of storage and compute.
63.
by tudorg 2y ago
That's very similar to what we are thinking as well, and we'd like to separate the Agent tools into an MCP server as well as use MCP for custom tools.
64.
by tudorg 2y ago
This is great, I like in particular that there are extensions plugins. I’ll be looking at integrating this in the Xata Agent ( https://github.com/xataio/agent ) as custom tooling.
65.
by tudorg 2y ago
Check out also https://github.com/xataio/agent which builds on this idea in the form of a dedicated agent for Postgres. Disclaimer: I’ve worked on this project.
66.
by tudorg 2y ago
That’s right, Aurora Postgres is quite close to vanilla Postgres. Aurora DSQL is a different story though. For a more scientific answer, there is this project: https://pgscorecard.com/ Note that Aurora scores 93% while Cock
67.
by tudorg 2y ago
It is a connection string for the direct queries, but also access to the metrics/logs via cloud specific tools. In case of AWS that's Cloudwatch. We do plan to add support for all the popular Postgres services.
68.
by tudorg 2y ago
There are things that can go wrong, but not so wrong to delete your data or cause outages. So there is a level of safety that I think is important at this moment. We do want to also allow executing generated SQL, but with an approval workfl
69.
by tudorg 2y ago
> I do wonder about cost of this at scale; compared to the cost of the services being monitored. Hopefully an Agent tax doesn't become another Datadog tax. One idea that we want to experiment with is that we let the model pick the n
70.
Launching Prequel: It's time for problem detection(prequel.dev)
2 points by tudorg 2y ago|0 comments
71.
by tudorg 2y ago
Ha ha, we're not wedded, I was only explaining why a .sql file is not quite enough. Using some json equivalent should be fine, thanks for pointing to the issue.
72.
by tudorg 2y ago
Yes, this is the biggest issue right now and we’re working on a solution. What we want to do is add the ability to generate the pgroll migrations based on the prisma generated migration files. Depending on the operation, you might need to a
73.
by tudorg 2y ago
I think it is fair criticism that this adds complexity. However, I do have a couple of counter-arguments: In order to avoid downtime and locking, you generally need multiple steps (e.g. some variation of add another column, backfill the dat
74.
by tudorg 2y ago
Actually no, this is a project by Xata. What link do you mean?
75.
by tudorg 2y ago
This is the font, we wanted something a bit different :) https://unbounded.polkadot.network/
76.
by tudorg 2y ago
Oops, fixing it now. This link should work: https://discord.com/invite/kvAcQKh7vm
77.
by tudorg 2y ago
Yes, but we're working on a converter from DDL sql to pgroll json. The reason for JSON is because the pgroll migrations are "higher level". For example, let's say that you are adding a new unique column that should infer
78.
by tudorg 2y ago
This does partially answer the biggest question I had about DSQL: how much of the incompatibility is “for now”, and how much will be eventually solved. It sounds like foreign keys and pl/pgsql will be implemented. Other things like aut
79.
Pgstream: Postgres replication events with DDL changes(xata.io)
8 points by tudorg 2y ago|0 comments
80.
Show HN: Pgstream – CDC tool for PostgreSQL with DDL support(xata.io)
8 points by tudorg 2y ago|0 comments
81.
by tudorg 2y ago
hi, yes, we are on AWS and offer several regions: https://xata.io/docs/getting-started/available-regions
82.
by tudorg 2y ago
[Author here] I'm sorry, I must have misunderstood or remembered old information (was it always like that?). I have fixed the phrase in the blog post.
83.
Schema changes and the Postgres lock queue(xata.io)
2 points by tudorg 2y ago|0 comments
84.
by tudorg 2y ago
Thanks a lot for commenting and pointing me to the blog post. I do think I've seen it before but forgot about it. I've re-read it now and it's a great read! From what I understand you decided to do sharding in the application
85.
by tudorg 2y ago
Thanks for noticing pgzx! We are working on a project building on top of it and going into the direction hinted by this blog post. I agree that the separation of storage and compute complements this nicely. In fact, we take advantage of it
86.
by tudorg 2y ago
> It does give a "When all you have is a hammer..." vibe to me and begs the question: why not use a system that's designed for use-cases like this and do it reliably and securely ? (disclaimer: blog post author) A reason w
87.
by tudorg 2y ago
Disclaimer: I work at xata. Xata is (like Heroku) based on Aurora, but offers database branching and has different pricing. That should be ideal for lightly-used test instances, because you only pay for storage, and 15GB are included in the
88.
Geographically distributed Postgres for multi-tenant applications(xata.io)
3 points by tudorg 2y ago|0 comments
89.
by tudorg 2y ago
My take: * When the pendulum has swung back from NoSQL, MySQL was in a weird place due to Oracle. * OSS project and foundation not dominated by any particular company means that startups are willing to bet on it. In turn, these startups bri
90.
Will PostgreSQL ever change its license?(jkatz.github.io)
4 points by tudorg 3y ago|1 comments

More ›