We went through the exact same dilemma with our product [1]. For desktop apps, one-off with a defined support window just feels right.
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.
Hey! Nice to see you have updated the pricing. I really liked the idea behind your product when I first saw it but the pricing was just a non-starter. Getting work to pay for all of my little productivity tools is a PITA and I still have side projects so spending a few bucks on a license every 2-3 years personally is where I find the sweet spot.
Will be trying out DB Pro again in the near future!
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...
TBH that part of your landing page exhibits some confusing UX. Perhaps it's just me but when I see a UI image with a play button I assume that clicking it is going to play a video, not redirect me to a login page.
I think there’s a big difference in commitment between the level of friction in signing up for a service and spending a couple of min on orienting myself and clicking play and watching the happy path go for 30s.
I started playing World of Warcraft at the same time I was studying database systems at university and had a similar curiosity. Twenty years later the AzerothCore project pretty much satisfies this curiosity, they've done an incredible job reverse engineering the game server and its database.
That’s fascinating. I didn’t realize the WoW server was so database heavy. do you know if the original game logic was implemented mostly in stored procedures, or was it just used for persistence and the engine handled the rules elsewhere?
It's not, no. The data you see in these files is reconstituted from the data that shipped with the game client, but they're not a perfect match for the real data.
The game servers are all C++ and don't use stored procedures for general gameplay management. They do handle inventory management so that item duping is generally not possible, and complex things like cross-server character transfer use stored procedures.
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.
SQL can make 2D data, but it extremely bad at it. It’s a good opportunity to wonder whether this part can be improved.
“Pivot tables”: I often have a list of dates, then categories that I want to become columns. SQL can’t do that so there is a technique of spreading values to each column then doing a MAX of each value per date. It is clumsy and verbose but works perfectly… as long as categories are known in advance and fixed. There should be an SQL instruction to pivot those rows into columns.
Example: SELECT date, category, metric; -- I want to show 1 row per date only, with each category as a column.
```
SELECT date,
MAX(
CASE category WHEN ‘page_hits’ THEN metric END
) as “Page Hits”,
MAX(
CASE category WHEN ‘user_count’ THEN metric END
) as “User Count”
GROUP BY date;
^ Without MAX and GROUP BY:
2026-03-30 Value1 NULL
2026-03-30 NULL Value2
2026-03-31 Value1 NULL
(etc)
The MAX just merges all rows of the same date.
```
SQL should just have an instruction like: SELECT date, PIVOT(category, metric); to display as many columns as categories.
This thought should be extended for more than 2 dimensions.
DuckDB and Microsoft Access (!) have a PIVOT keyword (possibly others too). The latter is of course limited but the former is pretty robust - I've been able to use it for all I've needed.
$ sqlite :memory:
create table t (product,revenue, year);
insert into t values ('a',10,2020),('b',14,2020),('c',24,2020),('a',20,2021),('b',24,2021),('c',34,2021);
select product,sum(revenue) filter (where year=2020) as '2020',sum(revenue) filter (where year=2021) as '2021' from t group by product;
One of the things that LLMs "excel" at, pun very much intended, is this exact pattern - creating filtered aggregates for a finite set of columns, and using this at the end of a CTE!
OP's example, for reference, was:
SELECT rank,
MAX(CASE WHEN file = 1 THEN COALESCE(piece, '·') END) AS a,
MAX(CASE WHEN file = 2 THEN COALESCE(piece, '·') END) AS b,
MAX(CASE WHEN file = 3 THEN COALESCE(piece, '·') END) AS c,
MAX(CASE WHEN file = 4 THEN COALESCE(piece, '·') END) AS d,
This pattern is incredible for generating financial model drivers (where every column is a calendar/fiscal month/quarter/year, and every row is a different type of statistic/measure).
The broader pattern is, in successive CTEs:
1. Group by Date w/ Aggregates
2. "Melt" to [optional groupings +] month + measure_name + value tuples:
select group, month, '# Bookings' as measure_name, num_bookings as value from base_data
UNION ALL
select group, month, 'Revenue', total_revenue from base_data
3. Then "pivot":
MAX(CASE WHEN month = '2019-01' THEN value END) AS "2019-01",
MAX(CASE WHEN month = '2019-02' THEN value END) AS "2019-02",
MAX(CASE WHEN month = '2019-03' THEN value END) AS "2019-03",
And what you get is a full analysis table, with arbitrary groupings, that can be dropped into an Excel model in a way that makes life easy for business teams.
And while the column breakouts are painful to type out by hand - they're very amenable to LLM generation!
Can you comment on whether you wrote the article yourself or used an LLM for it? To me it reads human (in a maybe slightly overly-punchy, LinkedIn-esque way), but a lot of folks are keying on the choppiness and exclusion chains and concluding it's AI-written.
I'm interested in whether others are oversensitive or I'm not sensitive enough... :)
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.
Coz theyre very reluctant to pay for tools and cant be bothered to lobby their boss for tool purchases for more than a couple of things.
If there's an open source version thats half as good or they can hack together their own version with bits of string they will usually do that instead.
Unfortunately I have a launch planned soon for a dev B2B product. I'm hoping that the combination of non AI coded work over many months combined with separating the docs intended for LLMs and thebdics intended for humans will break through the noise ceiling.
But, you know, maybe I should have just vibed it in a week and crossed my fingers.
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.
First of all, Homeworld was an iconic game for me growing up, so as other people have said, thank you for being apart of its creation.
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.
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.
[1] https://dbpro.app/pricing
reply