For vibe coders is it really “hours” setting up a database these days? GCP cloud sql + drizzle ORM is minutes and actually scales unlike a spreadsheet, heck Claude can even write you a deployment script and run it over GCP CLI.
Except the sheets-to-api SaaS charges $9/month if you want more than 250 requests.
A spreadsheet is a misclick away from corruption, why not spend another prompt on getting Claude to configure a db?
It's a shame that Google haven't managed to come up with a scale to zero option or serverless alternative that's compatible.
Unless things have improved it's also hideously slow, like trivial queries on a small table taking tens of milliseconds. Though I guess that if the alternative is google sheets that's not really a concern.
WTF is "Cloud SQL"?
I have a postgresql server running on a $5/m VPS that I add DBs to as and when I explore some new idea.
db-f1-micro is about $10pm inc storage for something that just works and can scale, be shifted on prem etc. you can run all your vibe coded slop on one instance.
I really wish auth was easier to setup for services though, i see no reason google can't provide this out of the box
For a serious database doing actual transactions, I'm not sure about the utility.
Thank me when things become super easy!
When things scale, SQLite will still be fine, will fit 99% of the vibe coders needs!
When they don't then migrate to what ever!
No it won't. SQLite is a poor choice at handling this, period. With all those hacks it still doesn't make any sense over something like PostgresSQL which is designed for that use case.
Yet another reason why I dismiss this nonsense of vibe coding.
A single vps like 1-2 GB ram and 2 CPU can suffice 100s of your projects
SQLite can handle 100s of users easyily
And 99% of vibe coded projects won't grow further than 100s of concurrent users
We feel that being able to build is becoming table stakes and the ability to actually get a product into people's hands is more important than ever. We built SheetNinja (https://sheetninja.io) to force ourselves to learn that side of the business from the ground up.
We chose a validated market (sheets-to-api) so we could focus on the "how to find users" problem rather than wondering if the category was useful. It also fits our current "vibe coding" workflow i.e. when we use LLMs or Replit to spin up an idea, a Google Sheet is often the fastest way to handle CRUD without the friction of setting up a traditional database.
We are looking for feedback on the tool itself and the landing page. We have a lot of visitors but a lower sign-up rate atm.
Thanks, in advance!
One thing I've noticed from the sheets-as-backend pattern: the reason people keep reaching for spreadsheets is because the editing UX is instant and familiar.Any tool that wants to replace this for non-technical users needs to nail that "just click a cell and type" experience. That's the hard part honestly.
I'll have to remember this for my next little one-off tool.
One feature suggestion: webhook support for row changes:
If my Sheet updates (say, a new waitlist signup), I'd want to trigger for e.g. a Slack notification. Supabase has something similar with their database webhooks. I use that extensively for kicking off signup workflows.
For your signup workflows, how sensitive would you be to latency? Would a 30 to 60 second delay be a dealbreaker, or are you looking for something that hits Slack the instant the row is created?
(The challenge with Google Sheets is we'd have to poll for changes)
How is this different?
Which scenarios do and which DO NOT require Sheet Ninja?
It's really good (no affiliation).
/* Uses: https://github.com/FCPS-TSSC/GQuery */
function exampleQuery1() { const gq = new GQuery(); const result = gq .from("Tags") .select(["ID","Name"]) .where((row) => row.ID == 12) // you can use > or < etc .get(); JSON.stringify(result, null, 2) }
I haven’t noticed a scrolling issues, btw
But Proton is really doing some great disservice to not having a public api for their docs.
I can imagine it being used for anonymous comments page for webpages etc.
I am not sure if there is something that you can do about it though given that the fundamental issue of this is caused by proton not having an api whereas I think google docs does have API.
It's more a message to proton if anything.
We're thinking of playing around with the pricing right now to make sure it is cheaper to just use this than to spend the time and tokens recreating the logic. We will see how it plays out.
You can publish any publicly readable sheet/form (append rows with publicly available form):
- sample sheet: https://veneer.leftium.com/s.1RoVLit_cAJPZBeFYzSwHc7vADV_fYL...
- sample form: https://veneer.leftium.com/g.chwbD7sLmAoLe65Z8
