Xtrable
A model is only useful if it reaches the systems that store data. NeoArc turns your model into a real database design, authored as its own thing so it can evolve on its own migration cadence, while staying wired back to the model it came from.
Four paradigms, one workflow
Different data wants different shapes, so NeoArc speaks all of them with a single, consistent way of working:
- Relational for SQL stores, with tables, keys and foreign keys.
- Document for Mongo, Cosmos and Dynamo-style stores, where you decide what to embed and what to reference.
- Wide-column for Cassandra and Bigtable-style stores, where the partition and clustering key design is the whole point.
- Graph for Neo4j and Neptune-style stores.
Real physical types, by engine
Your model describes intent in clean, abstract types. An engine profile resolves those into the concrete physical types and naming conventions of a specific database. NeoArc ships profiles for the engines teams actually run, including PostgreSQL, MySQL, SQL Server, Oracle, SQLite, Snowflake, Databricks, BigQuery, Redshift, MongoDB, Cosmos DB, DynamoDB, Cassandra, Neo4j and more, and you can author your own.
Switching target from Postgres to SQL Server is a change of profile, not a re-draw. Where a mapping loses fidelity, NeoArc tells you, so nothing is lossy by accident.
The model is the database, to start
One action mirrors your whole model into a database design: a table per entity, columns for properties, keys and foreign keys resolved, and the lineage wired in the same move. From there you refine. It is idempotent, so as the model grows you re-run it and it absorbs the additions without clobbering your edits.
Chain databases together
The world is rarely one clean model. A database in NeoArc can itself be a source for the next projection, so a schema or a downstream store can draw from an existing database just as easily as from the central model. Lineage follows the data across every hop.