Exactly. And most apps don't get there and therefore don't need it.
729 karma · joined June 13, 2018
But yeah, the page cache point is real and massively underappreciated. Modern infrastructure discourse skips past it almost entirely. A warm NVMe-backed file with the OS doing the caching is genuinely fast enough for most early-stage products.
What?!
Users get certainty, and you still have a clear path to future revenue when that window expires.
Subscription makes a lot more sense once you’re in cloud/collaborative territory which we've just entered. Sounds like you landed in a good place with this split.
I never considered that people want to watch a video in this day and age when they can try the real thing.
Perhaps I've fallen into that trap with the product [1] I'm building. I have a "Live Demo" button on the landing page and thought that would be enough? I'm going to reconsider...
I've always wondered what kind of stack games like EverQuest were built on.
"Sent from my iPhone"?
I had the idea of building a working Chess game using purely SQL.
The chess framing is a bit of a trojan horse, honestly. The actual point is that SQL can represent any stateful 2D grid. Calendars, heatmaps, seating plans, game of life. The schema is always the same: two coordinate columns and a value. The pivot query doesn't change.
A few people have asked why not just use a 64-char string or an array type. You could! But you lose all the relational goodness: joins, aggregations, filtering by piece type. SELECT COUNT(*) FROM board WHERE piece = '♙' just works.
My experience has been almost all positive.
Devs love to give feedback. Devs have decent paying jobs, and therefore money to purchase devtools (ours is $79) Devs love trying out new things and being early adopters.
Why is it a terrible market?
1. Keeping a consistent devlog on YouTube. It's the #1 source of traffic.
2. Getting a rank 1, page 1 HN post for a technical blog post related to our product.
3. Word of mouth. It's slow, but it works.
Just thought I'd chip in. The devlogs work the best though. Plus they keep momentum.
I just released support for dashboards. I've kept a devlog for the past 6 months.
And the biggest update is coming soon, DB Pro Cloud, which will let you connect to and manage any database through your browser as well as collaborate with your team.
Imagine Postman but for databases.
I could not agree more. It feels like the creativity is back. I grew up building fun little websites in the 90s, building clan websites for Quake 2.
That creativity died somewhere between Node.js, AWS, npm, and GitHub.
Some might say, well, that's growing up and building serious apps.
Maybe. But it doesn't change that I spent the last 15 years doing the same frontend / backend wiring over and over again to churn out a slightly different looking app.
The last 2 years have been amazing for what I do. I'm no longer spending my time wiring up front ends. That's done in minutes now, allowing me to spend my time thinking about solving the real problems.
At the end of the day, people pay to save time. Doesn't matter if it's been done to death.
What I'm most excited about right now is DB Pro Studio: a collaborative web-based version I'm building on top of it.
The idea is simple: databases are a team activity, but every DB tool treats them as a single-player experience. Studio adds either a self-hosted or managed hosted data browser, real-time collaboration, dashboards, visual workflow automation, and enterprise features like audit logging and role-based access. Think "database command center" where your whole team can inspect, query, and build on your data together.
The desktop app acts as the execution engine (your data never leaves your infrastructure), while Studio provides the shared dashboard layer.
I've also consistently posted devlogs on YT throughout the journey, which has helped build a community of ~1,400 subscribers who've shaped the product along the way.
Site: https://dbpro.app YouTube: https://youtube.com/@dbproapp
Would love feedback from anyone who's felt the pain of sharing database context across a team.
A couple of interesting observations while building it:
Yesterday the dataset had ~600 stations. Today it’s reporting 6,666 stations from the UK government feed, which is… a slightly ominous number, but according to the data and me asking an LLM, that’s close to full UK coverage already.
I deliberately went for a “pure speed” tech stack. Astro, no UI framework, just vanilla JS. Deployed on Cloudflare, with prices stored in D1.
I'm not using the API to load the data, I'm cleansing and then importing the CSV (which you can download for free) into the D1 database.
There’s also an /insights page with some aggregated stats that genuinely surprised me: https://petrolmate.co.uk/insights
Really nice to finally have an official, open dataset to build on. It already feels far more reliable than the old user-reported approaches, and it’ll be interesting to see how coverage and update frequency settles over the next few weeks.
Would love to hear feedback by the way. What is this missing to make it a genuinely useful tool?
DuckDB is on our radar. In practice each database still needs some engine-specific work to feel good, so a fully generic plugin system is harder than it sounds. We are thinking about how to do this in a scalable way.
PostgreSQL FOR UPDATE SKIP LOCKED: The One-Liner Job Queue https://www.dbpro.app/blog/postgresql-skip-locked
It covers the race condition, the atomic claim behaviour, worker crashes, and how priorities and retries are usually layered on top. Very much the same approach described in the old 2ndQuadrant post, but with a modern end-to-end example.
I'm planning to extend DB Pro into much more than a database manager though, letting you build dashboards, workflows and workbooks.
Neon support is on the roadmap though, and once I add it, it’ll be first-class rather than a checkbox integration.
Yep, it’s built with Electron. Performance has been a big focus from day one, and it’s been really performant in all of my testing so far. The goal was a proper desktop-first experience with local performance and direct database access, rather than trying to force it into a web app. Although I do have plans to offer a self-hosted version as well.
I’m building DB Pro, a modern desktop database client for developers who want a fast, local-first workflow.
I started in October 2025, launched v1 at the end of November, and just crossed $1k MRR.
I also post devlogs of life building and marketing DB Pro and am about to post devlog #4. The latest one is here if anyone’s curious: https://youtu.be/-T4GcJuV1rM
Still very early, but it’s been fun seeing something fairly “boring” resonate once the UX is treated seriously.
We are working on DB Pro, a modern desktop data workbench for developers and data engineers.
The focus is on going beyond a query editor and building a complete environment for working with data. Visual exploration, inline editing, dashboards, and Jupyter notebook style workbooks for queries, notes, and experiments all in one place.
We launched v1 a few weeks ago and the reaction has been genuinely jaw dropping. Downloads, feedback, feature requests, and some great long form discussions around real world data workflows.
We are documenting the entire journey through a public devlog series. The latest video covers the v1 launch.
Honestly, building a desktop app is so refreshing after spending a decade or so building web apps.