Graphweaver: a self-hostable GraphQL API over scattered data

The problem Graphweaver names: data scattered across SaaS and databases

The reason the project exists is stated in the first person in the README, and it is a complaint many teams recognise. Everyone has lots of sources of truth, a CRM holding customer data, accounting systems handling invoices, and more scattered across different SaaS platforms and databases. Syncing all of it is a real pain.

The earlier answer was to copy data from everywhere into one database, and the README says that always breaks at some point. The alternative the project proposes is not a sync but a facade: a single GraphQL API in front of all those sources, where a query can even span across data sources, the example being database records selected by a customer name that lives in the CRM.

That is a different architecture from the usual approach, and the difference is where the flexibility comes from. Most tools are oriented around a schema file, which the README says is fine until you reach production and need to override one operation or change exactly how auth tokens are handled. With Graphweaver, the API is described as a standard GraphQL server, so the behaviour can be tweaked in code however you like.

The homepage is graphweaver.com, the repository is under the exogee-technology organisation, the default branch is `main`, and the project carries a status badge reading active. The last push to the tree was on 2026-10-08, with releases v2.24.1 from 2026-09-22, v2.24.0 from 2026-09-14 and v2.23.2 from 2026-08-14 behind it.

Code-first, with overridable resolvers for the common cases

The feature list is the clearest statement of the design. An instant GraphQL API gives CRUD from any data source, a code generator introspects a database and creates TypeScript resolvers, and there are in-built resolvers for all common data access scenarios that you can override however you like.

The code-first part is what separates this from a schema-first tool. There is no schema file to hand over to a generator and then regret. The resolvers are TypeScript, in your project, and the type definitions are derived from the data source. When a query needs behaviour that the default resolver cannot express, you write the resolver rather than fighting a config file.

The data source list is broad: Postgres, Mysql, SQLite, SaaS platforms and REST are all named. The MikroORM and REST backends are the two that show up in the CLI's own prompt, and the ORM based ones suggest that the schema is derived from an entity model rather than raw tables in every case.

Cross source filters are the feature that makes multiple backends worth the setup cost. The README describes being able to filter across data sources, from one database by another, which is the mechanism behind the query that reaches across the CRM and the database at once. That is not a join in the database, it is the GraphQL server doing the work, and it means the performance characteristics are the server's rather than the database's.

The admin panel comes out of the box, and the README is blunt about the intent: you can customise it so that you do not have to build a back office system ever again. For a team that currently maintains a bespoke internal admin, that is the line item that decides the cost comparison.

The security model, all configured in code

The security features are listed as pre-built, and each one is a distinct layer you have to decide on.

Role Based Access Control defines permissions and access rights at a role level and assigns those roles to users. Access Control Lists define and apply permissions based on user roles and assign them to Create, Read, Update and Delete operations, so the granularity is per operation, not just per table. Row Level Security decides who can access which rows in the data source. Column Level Security gives fine-grained control over which fields and columns a user can access and modify.

That last pair is where a self-hosted data facade earns its keep. A CRM table and an invoices table rarely have the same sensitivity, and a single shared admin role across both is how a customer ends up seeing another customer's invoice.

Identity providers are pre-built for a local database and for Amazon Cognito. That is a narrow list, and it is the first thing to check if you are on another provider, because the alternative is writing the auth handling yourself, which is exactly the kind of thing the project says you have full freedom to do and also exactly the kind of thing that is easy to get subtly wrong.

The project points to its own security documentation for detail. The README does not describe the token format, the session handling, or how a denied request is shaped, so those specifics have to come from the docs site rather than from this page.

Creating a project with the Graphweaver CLI

The quick start is a short interactive flow. The prerequisites are stated up front: Node `>22.*` and PNPM `>9.*`, and the version constraints are given with a greater-than, so a newer major release of either is not assumed to work.

With those in place, a new project is created by running the CLI through pnpm's package runner.

`pnpx graphweaver@latest init`

The prompts ask for the project name first.

? What would your like to call your new project?
test-project

Then the backends, and the choices shown in the README are MikroORM with a PostgreSQL backend, MikroORM with a MySQL backend, and a REST backend.

? Which Graphweaver backends will you need?
◯ MikroORM - PostgreSQL Backend
◯ MikroORM - MySQL Backend
◯ REST Backend

Finally the confirmation, which names the target directory.

? OK, we're ready- I'm going to create a new app in "/Users/test-project" - is that OK?
Yes

All Done!

Make sure you npm install / yarn install / pnpm install, then run the start script to get started
❯

After that, you change into the created directory and install the dependencies with `pnpm install`, then start the development server with `pnpm start`. The server and the admin UI both come up on http://localhost:9000.

The full documentation, including installation instructions, API documentation and guides, is on the docs site at graphweaver.com/docs, and there is a hosted demo at demo.graphweaver.com that shows the shape of the thing without installing anything.

What code-first buys you and what it costs

The benefit is real and it is specific. A schema-first tool gives you a good API and then a wall, and the wall is met whenever reality diverges from the schema, which in a business integration is constantly. Here, the resolver is a function you own, so the query that spans a CRM record and a database row is a function you can write, and the auth token handling is code in the same repository as the rest of your business logic.

The cost is equally specific, and the README does not hide it. You now have a server you run, with a Node process and a connection to each backend, and a set of security rules expressed in TypeScript rather than validated by a vendor's console. Every role check, every row level filter and every token decision is code somebody has to read, review and keep correct. That is a genuine liability, and it is why the security documentation link is in the README rather than buried.

The other cost is the version relationship. Graphweaver is a framework with a CLI, a codegen step and a runtime, and the versions have to line up. Releases here are frequent, with three tagged versions in the last two months, which is good for fixes and means you will be upgrading regularly.

The project is also self-host only in practice. The README says easy to self host and points at a demo, but there is no hosted tier described, and the whole design assumes you own the deployment and the configuration of every backend connection.

Licence, maintenance and the shape of the repository

The licence needs reading carefully, because two sources disagree in a way that matters. The README carries a badge pointing at opensource.org/licenses/MIT and one of the feature bullets says 100% Open Source, available on GitHub under the MIT license, so you are free to change and deploy as needed. The repository's own licence field, however, is recorded as a custom licence that GitHub cannot classify, with the LICENSE file as the authority. A `LICENSE.md` file sits at the repository root. If your organisation's approval process needs a specific licence, read that file rather than the badge.

The repository layout is a single package with the sources at the root: `src/`, `docs/`, a `CODE_OF_CONDUCT.md`, a `CONTRIBUTING.md`, a `SECURITY.md`, a `.pre-commit-config.yaml`, a `.sonarcloud.properties`, a `.vscode/` directory and a `graphweaver.code-workspace` file. The pre-commit and SonarCloud configuration indicate the project expects a pre-commit hook and static analysis on contributions.

On maintenance, the picture is consistent. The repository is not archived, the last push was on 2026-10-08, and the three most recent releases are v2.24.1 on 2026-09-22, v2.24.0 on 2026-09-14 and v2.23.2 on 2026-08-14. The version number sits in the twenties of a two series, which tells you this API has been through a lot of shape changes and that upgrading across major versions is a project rather than a patch.

The project also ships an AI helper page for asking questions about the repository, which is a small thing to know about if you would rather read the source than a chat window.

Editorial conclusion

Adopt Graphweaver if your data genuinely lives in more than one place and you want one GraphQL API with permission handling and an admin UI over it, and you are prepared to own the server code and customise it in TypeScript. Do not adopt it if you want a hosted service with a fixed contract, or if your team would rather not maintain a Node service with a database connection pool behind it. Before installing, read the security documentation at graphweaver.com/docs/security and decide which identity provider you will use, since role based access, access control lists, row level and column level security are all configured in code rather than toggled in a hosted console.

Frequently asked questions

Official sources

1. exogee-technology/graphweaver on GitHub
2. Issues
3. Project website
4. README
5. Releases