StackRender and designing a database schema in a visual editor

What StackRender is trying to become

StackRender is described as the next-gen database schema design and generation tool, and the opening paragraph explains where it came from. It was born from the need to automate backend development, covering everything from the database to the final API endpoint, and the first step toward that long-term vision is a next-generation, free, open-source database schema diagram generator.

That framing matters for judging the project today. The stated end goal is much larger than a schema editor. The current deliverable is the diagram and the SQL, and the direction of travel is generating a whole backend from a specification.

The immediate value proposition is stated as going from specifications to a fully functional, production-ready database that can be exported in a preferred SQL dialect: MySQL, PostgreSQL, MariaDB, SQLite, Oracle, or SQL Server. The supported database list in the features section confirms all six, with a checkmark each.

The primary language is TypeScript, the licence is AGPL-3.0, the default branch is main, the homepage is stackrender.io, and the last push was on 2026-10-04. The releases are v1.4.0 from 2026-06-10 and v1.0.0 from 2025-08-22.

The status section is direct about where the project is: it is currently in Public Beta, with a request to star and watch the repository to get notified of updates.

So the audience is a developer or team who wants to design a schema visually, and the project is honest that the AI-driven part of the vision is not yet in the open source build.

The feature set, and the one that is cloud only

Six features are listed, and five of them are in the open source application.

The interactive diagram UI lets you design and manage schemas with a drag-and-drop interface. In-depth tables and columns control covers customising tables, columns, types and constraints. Index suggestions give recommendations to optimise database performance. Import and export of SQL DDL lets you either bring an existing schema in or export your design as SQL scripts. And foreign key cycle detection identifies and resolve circular dependencies in relationships.

The sixth is the AI-powered database assistant, and the parenthetical matters: it is a cloud version feature. It covers generating database diagrams from specifications and performing additional operations such as schema enrichment, soft-delete implementation, and automatic documentation generation.

That is the most consequential line in the feature list, and it is the boundary an adopter has to decide about. Two of the three named operations, soft-delete implementation and automatic documentation generation, are exactly the sort of thing that gets bolted onto a schema and then has to be maintained. If your plan depends on them, the open source build does not include them.

Foreign key cycle detection is the feature with the most engineering behind it in this list, and it is worth pausing on. A circular dependency between two tables is one of the classic schema errors that only appears when the migration is applied, and detecting it in the editor with a way to resolve it is genuinely useful. Most schema tools draw the graph and leave the problem to the database.

The topic list names the technology the tool is built with and the problem it is built to solve: database, db, db-migration, editor, schema-generation, sql, and then the database names themselves, mariadb, mysql, postgresql, sqlite. It also names the UI stack, react, react-flow and the newer xyflow, shadcn and shadcn-ui for components, and xlflow, which is presumably a charting or spreadsheet layer for the editor.

Running it locally with Docker

The recommended local path is Docker, and the commands are short:

# Build and run using Docker Compose
docker compose up

# Or build and run using Docker directly
docker build -t stackrender .
docker run -p 8080:80 stackrender

After that you visit http://localhost:8080 in your browser.

The compose file at the repository root is a single service. It builds from the local Dockerfile, tags the image stackrender:latest, sets the container name, publishes port 8080 on the host to port 80 in the container, restarts unless stopped, and sets NODE_ENV to production. The healthcheck is a wget spider against http://localhost:80/ every thirty seconds with a ten second timeout, three retries, and a forty second start period, which is the allowance for a first start that has to boot an nginx container and warm the static files.

The Dockerfile is a two-stage build. The builder is node:20 with the working directory /app, and the runtime is nginx:alpine, with the built dist directory copied into /usr/share/nginx/html and an nginx.conf placed as the default server config. The final image exposes port 80 and runs nginx in the foreground.

Two details in the builder are worth noticing. The npm install step disables strict-ssl, with a comment saying it is to handle potential certificate issues in some build environments, which is a pragmatic choice for a build that has to work across corporate proxies and a trade you should know about if you care about the integrity of what you fetch. And the build raises the Node heap with NODE_OPTIONS set to a maximum old space size of 4096, with a comment about preventing out-of-memory errors during the build, since a TypeScript project of this size will exceed the default heap.

The nginx frontend in front of a static bundle is a sensible production shape, since the application is a browser-side tool and the server is only delivering files.

Running it from Node.js instead

If you would rather not containerise it, the Node.js path is documented too.

For development, install the dependencies and start the dev server:

npm install
npm run dev

Then visit http://localhost:3000 in your browser. Note the port difference from the Docker path, which serves on 8080. The development server is Vite, and the script is the plain dev script in package.json.

For a production build:

npm install
npm run build

The build script in package.json is tsc followed by a Vite build, with the Node options raised to a maximum old space size of 8192, so the same memory reasoning applies here as in the container, only with a larger allowance.

The scripts section shows the rest of the toolchain. Linting is eslint with the .eslintrc.json configuration, applied to the TypeScript and TSX sources under src with the fix flag. Preview runs the Vite preview server, and the tests run under vitest, with a separate test:watch script for the watch mode. The repository has vitest.config.ts alongside vite.config.ts.

The dependency list explains a good deal about the application itself. The diagram canvas is @xyflow/react, the successor to react-flow, with @dnd-kit for drag-and-drop interaction, and @reecelucas/react-use-hotkeys for keyboard shortcuts, which for a canvas editor is a primary interaction surface rather than a nicety. The SQL editing side uses CodeMirror through @uiw/react-codemirror with the @codemirror/lang-sql language support, and @guanmingchiu/sqlparser-ts for parsing SQL, which is what makes the DDL import path possible. A large block of @radix-ui components covers the dialogs, menus, selects, tooltips and accordions that any settings-heavy editor needs.

The PowerSync packages are also in the list, with a drizzle driver, which is the persistence layer for a locally running tool that has to hold your schema offline.

The import and export round trip

The part of the tool that matters most in practice is the round trip between an existing database and the editor, because that is what determines whether the tool is used or abandoned.

Import and export of SQL DDL is described as letting you easily import existing schemas or export your design as SQL scripts, and the SQL parser in the dependency list is what does the reading side. That combination means a team with an existing production schema can bring it in, edit it on the canvas, and export the result rather than reconstructing the schema by hand.

The export target set is the six dialects listed, and the fact that Oracle and SQL Server are included alongside the open source databases is the interesting part. A tool that emits only PostgreSQL DDL is a PostgreSQL tool. A tool that emits six dialects is a tool for teams whose estates are mixed, and the dialect choice is the property that determines whether the exported script can be handed to whoever owns that database.

The cloud flow in the documentation makes the intended workflow explicit, and it is worth following step by step because it shows where the AI sits. You visit StackRender.io, click Launch the Web App, pick your database, then either import an existing database or leverage StackRender AI to create an initial database blueprint, edit and view your database, then export your Database SQL DDL and run it.

Note the shape of that sequence. The import path and the blueprint generation path are alternatives at the same step, which tells you the tool is aimed at both a greenfield schema described in prose and an existing schema brought in for revision. And the last step is running the DDL yourself, which is the correct division of labour for a tool that generates migrations: the tool proposes, the engineer's migration tooling applies.

Index suggestions and foreign key cycle detection sit alongside this as the two features that improve the output rather than just moving it around.

Where StackRender is the wrong choice

Three limits follow from what the project is and what it says about itself.

The first is the licence. StackRender is licensed under the GNU Affero General Public License v3.0, and AGPL is the clause that matters here. Its distinguishing obligation is that if you run a modified version of the program as a network service, you must offer the corresponding source to the users of that service. For a self-hosted internal tool inside one company, that is manageable. For a hosted service built on a modified StackRender, it is a genuine constraint, and a commercial team should read the licence text rather than the summary.

The second is the beta status combined with the AI gap. The project is in Public Beta, and the feature that would make it a specification-to-backend tool is explicitly a cloud version feature. So the open source build is a schema diagram editor with good export and import, which is useful, but it is not the automated backend development the introduction describes. The stated long-term vision is bigger than the current deliverable, and the README is honest about that.

The third is the deployment surface. Even the local Node path pulls in a substantial dependency set, and the Docker path deliberately relaxes SSL verification during the build. A tool that holds your database schema is not a high-value target, but it is also not a tool you want to bolt onto a sensitive machine without reading what it does.

The real alternative is the plain text route, and it is worth stating plainly. A schema written by hand in a migration tool, or in a .sql file reviewed in a pull request, is versioned, diffable, and has no dependency between a developer and the thing they are building. A visual editor earns its keep when the shape of the schema is genuinely hard to hold in your head, when many people need to review it, or when the diagram has to become documentation. If a team is small, the schema is stable, and nobody has ever asked for a picture of it, a text file is faster and cheaper.

Where a visual tool wins is the handover case. A schema designed by a domain expert and reviewed by people who do not read SQL needs a canvas, and StackRender provides one with the export path to make that handover actionable.

Editorial conclusion

StackRender is a good fit for a team that wants to design or document a database schema visually and hand the result to engineers as SQL rather than the other way round, because the export covers six dialects and the import path lets you bring an existing schema in to modify rather than rebuild it. It is a poor fit if you need the AI assistant, since diagram generation from specifications, schema enrichment, soft-delete implementation and documentation generation are described as a cloud version feature, and a poor fit for a fully self-hosted stack under AGPL terms. Before deploying, check the AGPLv3 obligations for your deployment model, and note the project is in Public Beta with the last push on 2026-10-04 and a released version of 1.4.0 from 2026-06-10.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. stackrender/stackrender on GitHub