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.
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.
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.
You have a very impressive list of investors and angels.
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.
Very excited to see someone is tackling this problem. With the rise of serverless, it's super easy for an average developer or a new developer to build a backend. It's also super easy to deploy a front-end with Vercel, Netlify, or GitHub Pages. But I believe there's no easy solution for the database part yet.
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 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.
Hey tudorg,
Really sorry if I posted this prematurely to HN... Came across the product on Twitter and it is an attempt to solve an incredibly common problem that me (and others in this community) break our heads around quite often!
Really looking forward to play around more with the product and I'm already on the waitlist :)
No worries :), and I'm glad that you did. It serves as good validation that we're working on something useful. We will be in touch to give you early access.
> 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.
Just to elaborate on the downvotes: it's really not 'industry standard' to connect to your database over GraphQL. I'm not saying nobody is doing it, or that it doesn't work well (for all I know, it might), but it's certainly not an 'industry standard'.
Hey there! Congrats on the landing page, it looks very promising.
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?
Maybe I'm in my bubbel since I'm the founder of another "database / backend" as a service company (https://nhost.io) but it's been a lot of new startups in this space which is fun to see.
- 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!
Bitter tale of a serverless experience: Serverless is great until you spend weeks building something in Cloudflare Pages and Workers, then add it to Google and... Google claims your site doesn't exist.
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.
I've also had the occasional issue with serverless platforms. Not to do with Google indexing, but I had a similar sensation: "well now we're just completely stuck". When something doesn't work the way it should, the whole premise of "you don't have to think about servers" quickly becomes "no, you're not allowed to see the servers" and its horrible.
These days I try to make the case at work for targeting containers and using the cloud platforms' container hosting tools instead.
You can use any external logging service that has an HTTP API.
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.
Are you thinking of Cloudflare Workers Sites? You can definitely do logging like that with Workers. But my understanding is that Workers Sites have been superseded [1] by Pages, and there are no logs for this new product other than at the Enterprise level.
It’s a database, an analytics tool, a search engine and a spreadsheet. Sorry, I just felt like I was watching late night TV shopping.
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.
I second the last paragraph. It’s a NIGHTMARE to sell SaaS to European Govs if it’s hosted with a US company (except, of course, you are one of said US companies. Then you can sell whatever you want. Yes, it’s really strange).
What is this exactly, a bit of a poor page/not developer friendly so who is the audience, people who use excel? Is it SQL? Key store? No examples just trying to get lots of catchy phrases/buzzwords on.
Yes, I admit the website is a bit high level. That is mostly because we're not yet quite ready to launch, we will have proper documentation once we do.
At risk of being a brusque, why are you posting this then? It's a waste of time. If you had posted rough technical details of your initial offering you could have gotten real feedback before the launch of the product itself.
I understand. We didn't post this ourselves, however a Techcrunch article about our funding round was posted today, and then someone else has posted this to HN.
Nice to see more possibilities in this space, database branches look particularly interesting and useful for the JAMstack world! That's definitely something that's hard to manage in CI/CD for JAMstack apps.
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.
How big is the market for this I wonder? I run a product like it for free for 15 years now and while it has 100000s users and 1000s of companies running off it, there are only a few who would not skip to self hosted/cloud hosted instead of paying us. We are fully free (no pricing page) but we talk to our users and some sponsor us (just send some money to PayPal willy nilly when they feel like it) ; most of them say they like our solution better than others however they would just pop their own server if we would charge. Seeing how much excitement this brings, I guess I should try adding a pricing page and calling their bluff.
I use Firebase. Most projects don't need more than the free tier. A few are on the paid tier; however, the monthly cost is covered by revenue and way below the cost of running our own infra. I would not switch services/host a backend just to save a few hundred bucks. Call their bluff.
I did not want to take away from this 'launch' ; We are redoing the front-end (as it looks 15 y/o) and are almost done redoing it. We integrated a lot of to get a bit more modern in that version and we have an API now that allows x origin so it can serve serverless. For the API you will have to email: have 1000+ companies using it, however, I did not advertise it until the site has been redone. It is mobile unfriendly but it was never meant to do that.
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.
Why would anyone use this as opposed to the DB offerings provided within the respective serverless cloud platforms? I think cloud platforms also charge more for egress to 3rd party services as well
I think the spreadsheet view isn't that big as big a deal as its position on the page suggests. The branching however, is actually pretty awesome.
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)
Nice landing page but very little in terms of how this actually works. Also no pricing so I can't anticipate how much this might cost me. Speaking of pricing: any chance there wil lbe a free-forever tier?
Looks promising. Platforms such as Netlify have greatly simplified the development of web applications. Recently I tried Netlify forms - child's play, in 4 minutes I had a working form with e-mail notification. All I had to do was create the correct HTML code. If they simplify the use of the database in simple projects in a similar way, it will be a great success.
I know this is petty and arguably irrelevant, but I hope you find the feedback useful. The spacing and alignment on your some of your visuals is sloppy and distracted me from your otherwise well put together messaging. The row level security graphic is the one that stands out the most in this regard.
> What is a "connectionless api"? I have not heard that phrase before?
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.
Thanks for the reply. Feedback would definitely be to include this sort of technical detail on the site!
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.
I had recently come across postgrest.. API on postgre SQL. Is this on similar lines (obviously xata looks more robust, feature rich than postgrest, but are on the same lines?)
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.
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.
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.
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.
Really looking forward to play around more with the product and I'm already on the waitlist :)
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!
- 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.
These days I try to make the case at work for targeting containers and using the cloud platforms' container hosting tools instead.
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.
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.
[0] https://flexlists.com
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.