Neurelo is a platform designed to simplify the process of working with databases for developers. It offers features such as building and managing schemas with Text-to-Schema support, auto-generated and editable migrations, REST and GraphQL APIs (with SDKs) generated from your schema with documentation and a playground, custom API endpoints for complex queries with Text-to-SQL/MQL support, multiple CI/CD environments, schema-aware mock data generation, and more.
Neurelo provides tools for interacting with databases and offers an abstraction around database access, while still maintaining control. It supports MongoDB, MySQL, and PostgreSQL on any cloud or on-premises with a "bring-your-own-database" model.
One of Neurelo’s core features is the easy management of schema evolution over time. Database schemas are represented in a JSON schema format we call a “metaschema” – a (JSON) schema for defining (database) schemas. Schemas can be crafted and edited in multiple ways:
You can freely switch between these methods while defining or updating your schema. Changes made with one method are immediately reflected in the others. For example, you can introspect an existing database to infer the current schema, use the AI prompt to propose a change, view it in the visual editor, manually adjust as needed, then commit the schema and share it with a coworker for further testing.
Each version of a schema is stored in a Git repository. When you create a project, you can either provide an external Git repo for Neurelo to utilize or have one created and managed for you. You aren’t tied to any specific Git hosting; whether you use GitHub, GitLab, another service, or host your projects on a personal server, you just need to provide a URL and permissions via either SSH (by granting access via a public key) or HTTPS (by adding an access token to the project).
Neurelo also includes a built-in ERD viewer for visualizing the schema.
Because the schema contains the necessary information to read or write to the database, Neurelo can automatically launch a server providing access via either REST/JSON or GraphQL. Each entity in the schema has endpoints for CRUD operations with common options like filtering, projecting, recursive lookup, or creation of related entities. Once you commit a schema, you can deploy a live version of the server in Neurelo for your application to use instead of directly connecting to the database. An API playground is also available for testing and building out your API and SDK calls.
Importantly, the database access code isn’t hidden when using the auto-generated APIs; each endpoint provides a “query visualization” option, showing the raw query executed alongside the response.
In addition to the automatically generated API endpoints, you can define and test custom endpoints using raw queries (i.e., SQL or MQL, depending on your database choice). Custom queries are version controlled alongside the schema, ensuring you always have a complete version of the API your application used if you need to roll back.
Custom queries are a key part of the theme of how we make sure that you can retain full, fine-grained control over any or all of your queries without forgoing the benefits of using schema version control and a database-agnostic API. Combined with the ability to observe the raw query executed by any autogenerated endpoint, you can verify query efficiency and replace it with a custom query if necessary.
Comprehensively covering everything Neurelo can do would be overkill for this overview, but a few other features are worth calling out:
Some of the features described above might sound similar to the benefits that are offered by ORMs; for example, automatic generation of high-level abstractions to wrap database queries and the ability to check models in version control are both things an ORM can provide you as well. This isn’t accidental; Neurelo is designed with similar goals of improving developer experience around user databases, but we also strive to avoid many of the common pitfalls that occur when using ORMs in real-world development.
One way that some ORMs often cause friction is the lack of transparency in how queries are actually resolved. While being able to query by describing the objects to get from the database can be powerful, it’s not always intuitive how this will actually translate into a raw database query. This can lead to the infamous “N + 1” query problem, where multiple database calls are used to obtain the set of results rather than combining all of the logic into a single query.
Neurelo provides several features to mitigate this issue. As mentioned above, every auto-generated API endpoint gives the developer the ability to obtain the raw query used under the hood. Rather than trying to mask the lower-level database details, Neurelo intentionally gives developers the ability to leverage their SQL/MQL knowledge to verify that queries are efficient. Combined with the ability to define custom endpoints with raw queries, developers can have full control over the exact queries being executed.
Although many ORMs provide the ability to “drop down” into a raw query for performance reasons, it comes at the cost of the benefits of using an ORM; instead of being able to cleanly abstract the database-level logic from the higher-level application code, using a custom query with an ORM requires lifting the database logic into the codebase.
Neurelo’s custom queries don’t suffer from the same issue. Your database access abstraction remains clean – using APIs. Custom queries are defined alongside the schema and kept in the same version control, and changes to them are decoupled from changes to the application. If you optimize a custom query to return the same results more efficiently, the application code won’t need to change, which means you won’t need to redeploy your application.
Using a third-party software product always comes with the risk of vendor lock-in. The benefits of any product, especially a “service” product like Neurelo, needs to be weighed against the potential cost of needing to migrate in the future for any number of possible reasons (e.g. degradation of quality, failure to grow with additional needs, untenable increase in pricing). It’s not reasonable to ask customers to blindly trust a software vendor, and even a well-intentioned provider can’t feasibly guarantee that future owners will continue acting in good faith.
To that end, Neurelo’s approach to mitigating fears of vendor lock-in is to provide concrete ways for users as insurance against future issues, and where possible, to allow users to decide for themselves how much to “hedge” their investment in using Neurelo. For example, we chose to represent schemas in a format defined by JSON schema, a widely-used open standard. If Neurelo users decide to migrate away in the future, they can leverage any existing tooling that supports JSON schema to aid this process. Similarly, using your own git repo to store the schema history and migrations gives you full control over what happens to it if you leave; removing our access to the repo only requires revoking an access token or ssh key, and you can freely track the changes in another git remote that we don’t have access to (or even treat that remote as the source and sync the changes “downstream” to the repo we’ve been granted access to). You don’t need to trust that we won’t cut your access off to your schemas when you can make it impossible for us to do that! Likewise, Neurelo uses a “bring-your-own-database” model rather than managing your database ourselves. Nothing stops you from revoking the credentials we use to access the database or removing incoming firewall rules allowing access from our network at any point in the future.
Another feature that can help hedge against lock-in is mentioned a few times above–query transparency. Distinct from security concerns is the risk of investing significant software development effort to use a platform only to move away from using it in the future. While it’s impossible to completely eliminate any sunk costs, if you decide to stop using Neurelo in the future, you can easily get the raw queries used by both autogenerated endpoints and custom queries to ensure that you can reproduce all of the queries by accessing the database directly.
One remaining feature of Neurelo only tangentially referenced above is our rich suite of integrated AI tools to help make defining schemas, queries and using APIs easier. AI assistance is opt-in and available when needed. For example, you can prompt the AI with instructions like “define a schema for a restaurant” or “write a query to retrieve all employees hired in the last month.” AI tools generate output in the same format you could define manually, allowing you to modify the schema or query as needed.
Significantly, AI is only used as a tool to help define schemas and custom queries; autogenerated API endpoints use queries generated deterministically based on the schema, and no AI is used when executing operations received by the API server. AI is only used as a tool at the step where schemas and custom queries are defined, and even then only when explicitly invoked by the user.
If you're interested in experiencing a faster and more efficient approach to building applications with PostgreSQL, MongoDB, or MySQL, give Neurelo a try. We would love your feedback!
