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.
I'm building DB Pro, a cross-platform database management app that lets you browse, query, and manage SQLite, PostgreSQL, MySQL, Redis, MongoDB, and more from a single native interface. It's been growing steadily with a community of ~1,400 subscribers on YouTube and paying users.
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.
Developers are pretty willing to pay for tools that save them daily friction, even in crowded spaces. I find that the trick is finding the wedge that makes yours feel essential rather than nice-to-have.
At the end of the day, people pay to save time. Doesn't matter if it's been done to death.
If you want to go a step further the PostHog roadmap items are all GitHub issues that users can upvote which gives a great sense of who wants what in the community.
I find that when people can see what's coming, they're more invested in the product and more likely to share feedback that actually shapes the direction. The devlogs on YouTube serve the same purpose. It's a two-way street.
Thanks Steve! The team angle came from mine and my co-founder's own frustration. We kept copy-pasting query snippets and results of queries into Slack/Teams to our engineering team but also Sales/Marketing etc. Figured there had to be a better way. If you ever want to give it a spin, I'd love to hear your thoughts.
I've honestly been looking for this -- a modern slick db management app, both for local dbs and remote (just for me though, no collaboration). Existing tools are solid but they feel outdated.
Downloaded and onboarding was nice. A couple of things:
- The initial schema for my local Postgres table was showing public but there were a bunch of tables showing that clearly were not tables in my public schema. Changing the schema to something else and back worked.
- Limiting the free version on number of tabs feels... annoying. I appreciate that a lot of stuff out there doesn't even have a free version but the software automatically opened with a few tabs (or I accidentally clicked on it?) and then as soon as I clicked on my first table I was paywalled. I feel like I'll accidentally open more tabs (even though I really just wanna work on one at a time) and get frustrated, which is more likely to drive me away than to pay at this point.
Note btw that ofc you have to make money and this is a product that I feel I'd be willing to pay for but I got frustrated within 2mins of using it so it wasn't like oh I've felt the value let me pay, it was more like I haven't even gotten to value yet.
Great work anyway and I'll keep trying and provide feedback as it comes! Thanks for building this
I spent the last few hours hacking together PetrolMate using this dataset: https://petrolmate.co.uk
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.
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?
Thanks for putting this together!
Couple QoL features I'd love to see:
1. filter slider, decreasing on price, to see places closest to me disappearing
2. on the left panel, when I click on a low priced area, it should highlight it on the map, so I know where it is. The 'go to pump' button, I guess is good. but I'd only want to commit to gmaps if I already know that it's a reasonable place for me to. be going.
reply