PgWebTool, or PgWT, is a content management system being built by The JCArtes Foundation. It does the job WordPress does — run a website you can edit without touching code — and it is built on C/C++ and PostgreSQL. It is open source, it is not finished, and there is no public repository yet.
That last sentence matters. This page describes what is being built and why, not something you can download today. When there is code worth looking at, it will be linked here.
Why Build Another One At All?
WordPress runs a large share of the web and does a great deal right. The complaint is not that it is bad software. The complaint is what a working WordPress site actually becomes after a year or two.
Ask what it takes to run an ordinary small site properly. You need caching, because the stock installation is slow. You need image handling, because uploading a photo from a modern phone puts a four-megabyte file on a page. You need minification. You need an SEO plugin, because the metadata handling is thin. You need something for a shop. You need something for translation. Each of those is a separate plugin, from a separate author, on a separate update schedule, with a separate idea of how much of itself to withhold for the paid tier.
So a site that is conceptually simple ends up depending on a dozen strangers, any one of whom can break it, abandon it, sell it, or start charging for it. Most people running a small site have no way to judge which of those dozen is trustworthy, and no way to recover when one of them stops being so.
PgWebTool takes the opposite position: the things practically every site needs should already be there.
What Goes In The Base Package
These are not planned as add-ons. They are the parts a site is expected to need, so they belong in the thing itself:
- eCommerce
- Caching
- Image handling
- Minification
- SEO and metadata
- Website translation
There is still a plugin system, because no one can anticipate everything. But the aim is that most of what people currently install plugins for is simply unnecessary.
And there is one version. It is free, it is open source, and nothing is held back to sell later. The Foundation does not ship a crippled edition and call it the free one.
Why PostgreSQL
PostgreSQL is the reason the project is named what it is. It is a stricter, more capable database than the MySQL and MariaDB that WordPress grew up on: it has a real type system, it will refuse data that does not make sense rather than quietly mangling it, and it handles structured and semi-structured data in the same engine without needing a second one bolted alongside.
For a content system that matters more than it sounds. A CMS spends its life storing things of uncertain shape — posts, metadata, settings, whatever a plugin decided to put somewhere. A database that enforces meaning is a better foundation for that than one that accepts almost anything.
Why C And C++
The deciding factor was maturity, and it was settled by trying the alternative rather than by arguing about it.
I do not consider Rust to be a reasonably mature language yet. That judgment comes from three places: using it myself, watching AI systems generate Rust code, and the PgWebTool work that was actually attempted in it. C and C++ are mature by a wide margin. For infrastructure meant to sit quietly under somebody’s website for a decade, that is not a minor preference — it is the whole question.
Plenty of capable people will disagree, and they are welcome to. This is a conclusion drawn from doing the work, not a prediction about what Rust may eventually become.
There is a second reason, less arguable. The hardware side of this Foundation is electronics engineering, and C is the native tongue of that world. Writing the software in the same language as everything else is not a compromise here; it is the obvious choice.
A Short Story About Taking AI Advice
PgWebTool was briefly started in Rust. That was not the plan, and it is worth explaining how it happened, because it is a small example of the thing this Foundation keeps arguing about.
The suggestion came from an AI assistant, and I took it seriously. I was genuinely open to Rust. I trusted that the system was clever enough to know something I did not — which is a reasonable thing to think, and precisely how this sort of mistake gets made.
So the project started in Rust, and it was a real attempt rather than a token one. A working prototype exists to this day, with its Cargo files and its handlers and its migrations, sitting in a folder nobody opens.
I was wrong to defer. Not because the advice was careless — it was fluent, confident and internally coherent. It was wrong because it came from something with no stake in the outcome, no experience of maintaining the result, and no memory of why the original decision had been made. The trial is what settled it: having written the code, I do not think Rust is mature enough for this job, and C/C++ plainly is.
This is exactly the failure mode described in The Folly Of LLMs And Neural Networks. A language model produces plausible text. Plausible is not the same as correct, and it is not the same as understanding what you are actually trying to build. The cost here was a few weeks and some abandoned code. In other settings that same confident wrongness costs a great deal more.
The lesson is not that AI advice is worthless. It is that it has no skin in the game, and you do. When it contradicts a decision you made deliberately, the burden of proof is on the machine.
Where It Stands
In development. No public repository yet, no release date, and no promises about one — this Foundation has already learned what a missed date does to an argument.
If you build software and this sounds like something you would use, the most useful thing you can do right now is say so, and say what you would need from it. Write to Support@JCArtes.Org. Knowing what people actually want from a CMS is worth more at this stage than another pair of hands.