Xata – Database service for serverless apps
xata.io
xata.io
I am Tudor, CTO at Xata.
Thanks for posting the link! We’re not yet ready for you to try it out, so it is maybe a bit too early to show it to this community. We will probably do a proper Show HN post once we are ready.
Nevertheless we are thrilled to be here! :)
For a few more details, see also our first blog post: https://www.xata.io/blog/hello-world/
We’re building a database service that is extremely easy to use (think of Airtable and its rich data types), yet providing the usual guarantees offered by traditional databases (consistency, transactions, constraints). We also have a built-in analytics and search engine, so you no longer have to copy the data from the DB to the search engine. There are other features that we’re really excited about (native branches, easy-to-use joins, caching, security rules), but we’re going to be able to talk a lot more once we’re ready for users.
We’d love your feedback and if you’d be interested to work with us, please don’t hesitate to reach out.
For most people, the most common choice is to use Firebase. Firebase offers services that people can use to build a "full-stack" application, from front-end service, serverless function as a backend, and a database. It's very tempting to use Firebase for a new developer. Now we also see the rise of Supabase, that offers an alternative to Firebase, that's built on top of open source projects.
I believe in the future, it should be the norm to include database to an application with just a single env variable, without worrying about anything else.
I some how doubt it. Firebase (and these kind of proprietary services in general) are a complete nightmare for larger production apps: limited query power, doesn't actually scale like it claims it does, difficult to test locally, etc.
A traditional backend with a Postgres database and plain REST APIs using hosted on something like Heroku is much simpler.
Is it NoSQL / NewSQL?
Distributed by default?
Global? serverless apps run at the edge. The database (or its read-copies at least) then could not oceans away? see: macrometa.com / workers.dev kv
Based on any open source backend like Postgres or OpenSearch? see: rocketset.com / quickwit.io / timescale.com
Will it have a free-tier?
Any tentative launch dates?
Thanks.
> Is it NoSQL / NewSQL? > Based on any open source backend like Postgres or OpenSearch?
Yes, we are basing our implementation on Postgres + Elasticsearch. However, we don't plan to offer direct access to the Postgres/ES APIs, so we see them as an implementation detail (an important one, of course). We will have our own API which will allow us to develop features like no-downtime migrations, branching, and caching.
> Will it have a free-tier?
Yes, absolutely! And we plan to make it in such a way that it will be production ready and all you need for a personal project or simple website.
Please please use an industry standard layer like Graphql. Otherwise it becomes very very hard to push for adoption here.
As for the database and search engine, are you building on top of existing systems a unified API? i.e. are you building a smart layer on top of PostgreSQL for DB and Elastic for search?
Thanks!
One thing I have realised recently is that, even when someone has a good product, you have be to be very strategic with fundraising in Devtools and enterprise space. Doing it really well is an art and I think you guys are executing really well on that front. Good luck!
I was wondering when did you guys actually start before you came out of stealth mode.
Really looking forward to play around more with the product and I'm already on the waitlist :)
Excited to see another player join the field. DBaaS seems to be rapidly evolving and it looks like there will be a lot of new developments in the next few years to help reduce the overall dev effort.
My apps need wafer thin business logic and most of the server apis that I write are just thin wrappers around the db query and auth.
As a hopeful JAMStack dev, i don't want to work on a server at all. My expectation is that the service should provide me the server and the db together
I just want to create a SPA/PWA and link it directly to the service provider apis.
Just adding my wishlist, in case it helps
- Rest api with user defined endpoints (or a single endpoint with function name as params)
- functions layer before the db queries
- globally available/provisionable db
- exportable db data to prevent lockin
- OSS auth implementation that can be taken anywhere
- integration with Oauth providers like Google, Apple, Github, Twitter etc.
- Protection and Analytics built in
- Competitive Pricing
Right now, I am not getting on the JAMSTACK wagon, because I am not finding a lot of SaaS provider which caters to all my needs. Firebase, Supabase and nHost, are the only ones which come to mind which can do what I hope should become common place in the market.
- Firebase
- Nhost
- AppSync
- Supabase
- 8base
- AppWrite
- Xata
I like your focus on workflow, PRs, branching etc. I think it's going to be key to solve end-to-end problems for developers in the future.
Congratulation on the raise and I'm excited to test our your service once it's launched. Good Luck!
- FaunaDB
- Macrometa
Search Console Live Test gives a vague 'General HTTP Error', Rich Results Test says the 'page is unavailable', Ad Words says 'Destination not working'. Bing indexes your site with no problems, and every device you and your friends own works fine, every uptime tester on the planet says you're good. Cloudflare shows no firewall events and logs are a 'contact us for pricing' Enterprise-only feature.
So what do you do - if Google thinks your serverless site doesn't exist, and you can't debug it because it's all magic? You can't do anything. Back to conventional hosting you go.
Not ideal, but it works fine.
I'm doing this with Cloudflare workers by sending access logs to a self hosted Matomo analytics and error logs to Loggly.
But in general, Cloudflare isn't really suitable yet for general app development. They need a lot of additional services for that to become viable, imo.
[1] Documentation for Workers Sites at https://workers.cloudflare.com/sites redirects to Pages
The workers act as a middleware. You can `fetch` the static content and then do any processing/logging you want.
These days I try to make the case at work for targeting containers and using the cloud platforms' container hosting tools instead.
As a product this makes some sense, but as with most new products, on-prem is ignored. We’re moving more customers off public cloud than we help launch new product on cloud offerings.
The current situation in the EU makes these SaaS offerings almost irrelevant. Companies and governments are very reluctant in picking any cloud services.
It's also interesting to see more database services support HTTP APIs. SingleStore recently launched support for an HTTP API as well (https://docs.singlestore.com/managed-service/en/reference/ht...). I think most database services should follow suit due to how popular serverless frameworks are becoming, and the need to have connectionless pooling. I have some questions such as:
* Will all these HTTP APIs support most authentication methods already used by these database services? Or will they likely only support some sort of API token based auth?
* Could HTTP caching ever be useful for these? Or just internal database caching?
* Is security a concern any more so than with regular TCP connections?
* Will all your typical ORMs "just work"? I think the answer is "yes", but there are some more modern ORMs that I wouldn't be too sure about (e.g. Prisma).
Disclaimer: I work at SingleStore, which is a database service for data-intensive apps as well.
I'm most excited about the support for "better" migrations and interaction via a GUI.
While we're not strictly Jamstack, I could absolutely see us using this as an auxiliary to our primary production database, i.e. for prototyping or launching new features rapidly without having to migrate the full prod schema.
To use this alongside our production dbs, my wishlist would be:
1. A way to "eject" to raw postgres/etc, gives me peace of mind that if things don't work out, I can still take my pg_dump and go home. 2. Maybe a Prisma.io integration?! Would allow it to play nicely with out non-serverless backend, while ALSO catering to serverless applications.
Just some thoughts!
Seems like you just need to define a free tier and figure out where the cutoff is for more serious use.
My main goal, because I use it for everything, is speed: entry speed, reaction speed etc. So apologies to xata, I do not see myself as a competitor, but here is the link [0]. Just email me for the new version, the api and cors.
On a 24" screen, the features are all below the fold. Above the fold is taken up by a huge hero section that looks nice, but is taken up by a huge animation and a header that's mostly buzzwords. You do have a paragraph with some good info, but really doesn't catch my eye. I literally had to scroll down 2-3 screen heights to get to the first feature that stood out to me (and that paragraph I mentioned didn't even feature it)
Double down on what sets you apart.
As for "too early" - well, yes. Sounds good in theory, except there's absolutely no detail from both a developer or a founder's perspective.
That is, can't provide feedback when there's nothing apart from the landing page to evaluate :/
Some preliminary API docs maybe? Those should spark a discussion pretty well imho
What is a "connectionless api"? I have not heard that phrase before?
Can I use this instead of DynamoDB global tables? Where does it sit RE CAP?
It just means that we offer an HTTP based API, so you don't need to do connection pooling. This is convenient for serverless apps, because they can't hold onto a connection.
> Can I use this instead of DynamoDB global tables? Where does it sit RE CAP?
Yes, we do want to be an alternative to DynamoDB global tables, but with a more flexible data model. The in-region writes/reads are consistent, the replication to the analytics/search engine as well as replicating between regions are eventually consistent.
Would love to dive into the details of how you guys are doing DNS resolution (latency based routing?) how many regions you have, if we have control over how many regions we replicate to etc. We are building a global edge API for https://flagsmith.com/ and this is a great candidate for a data platform for us.