DEV Community: Artemiy Vereshchinskiy

How an app for CD collectors accidentally became infrastructure for AI agents

Artemiy Vereshchinskiy — Mon, 06 Jul 2026 13:28:58 +0000

If you told me back in 2014 that an idea for helping CD collectors would eventually become AI infrastructure, I probably wouldn't have believed you.

But looking back, the path actually makes sense.

Also, fair warning: this is a pretty personal story. It’s less about features and more about how an idea slowly evolved over time.

It started with a duplicate CD

Back in 2014 I was visiting a friend.

His father is a serious CD collector. Thousands of CDs.

One evening he came back home, and a minute later we heard lots of shouting and a few colorful words coming from the living room.

He had just bought a CD he already owned.

Again.

Later during dinner he said something that stuck with me.

"What if there was an app for a phone? Something more handy than keeping everything in Excel on those smartphones. Just something to quickly track my stuff and know what I already have."

At that point I wasn't a software engineer.

I worked in IT support and occasionally built WordPress websites.

So naturally I thought:

"That shouldn't be too difficult."

(I guess most burnouts started with the exact same thought)

It turned out to be one of the hardest problems I've ever worked on.

The problem wasn't storing data

Initially I thought I was building software for collectors.

Then I started talking to collectors.

That's when I realized the actual problem wasn't collecting things.

It was that everyone thinks about their collections differently.

One vinyl collector organizes records by pressing year. Another by matrix numbers. Someone groups everything by country. Someone else keeps collections inside collections. Others care more about stories and memories than metadata.

Every time you introduce a predefined schema, somebody immediately becomes constrained by it.

I didn't want software that tells people how they should organize their collections.

I wanted software that adapts to how people already think.

Around that time, I also realized this wasn't just an abstract problem for other people. In my own family, collecting has always been a generational thing: poststamps, minerals, coins, vinyl records. My dad is a true metalhead with his own carefully curated collection. That made it clear to me that this idea shouldn't be limited to CD collectors. The goal naturally evolved into something broader: a system that could serve all kinds of collectors at once, regardless of what they collect or how they think about it.

The goal became surprisingly simple to describe:

Let people organize, group and nest information however they want.

Then somehow make that information searchable, traversable and filterable as if somebody had spent months designing a perfect relational schema.

Marketplace-style facets.

Dynamic filters.

Relationships.

Exploration.

Without manually defining any of them.

This was before the tools we have today

Today we have Notion.

Airtable.

Flexible databases.

AI.

And, of course, vibe coding.

Back then, none of that existed.

I started building a WordPress plugin called Collect.

Very quickly I realized I had absolutely no idea how to build the system I had in my head.

So I abandoned it.

A year later I came back.

Then abandoned it again.

Then rewrote it.

Then forgot about it for another year.

Eventually I accepted that solving this problem required becoming a much better engineer than I was at the time.

Looking back, this project is probably one of the main reasons I became a software engineer.

The problem kept following me

Years passed.

I worked on different products, backend systems, distributed infrastructure and AI.

But every time I returned to Collect, I noticed the same pattern.

Collectors weren't unique.

Everyone produces messy data.

Companies do exactly the same thing.

REST APIs return arbitrary JSON.

Mongo collections drift over time.

Relational schemas evolve.

Documentation becomes outdated.

Every organization ends up accumulating semi-structured information.

Everybody wants flexibility.

Everybody still expects fast search, filtering, analytics and navigation.

The collecting problem wasn't a collecting problem anymore.

It was a data problem.

At this point, attentive readers might reasonably ask:

"Wasn't MongoDB designed exactly for this kind of uncertainty?"

And that's a fair question I asked it myself many times during this journey.

MongoDB does embrace flexible schemas and allows you to store arbitrary structures without enforcing rigid definitions upfront. That part aligns well with the original goal.

But the challenge I kept running into wasn't just storing uncertain data.

It was understanding it efficiently.

Things like cardinality, facets, and dynamic filtering across arbitrary properties become surprisingly expensive. In practice, they often require full scans at query time or some form of precomputed, tenant-specific caching that quickly becomes complex and brittle.

In other words, the schema effectively exists only at read time.

For Collect, I needed something different.

I needed the system to continuously understand the structure of the data as it was being written, so that exploration, filtering, and discovery would feel instant and natural, not reconstructed on demand.

This wasn't about rejecting existing tools.

It was about realizing that the problem I was trying to solve lived slightly beyond what they were optimized for.

Somewhere along the road Collect became RushDB

As the project evolved, I stopped thinking about collections.

I started thinking about data itself.

One observation kept bothering me.

Most databases are very good at storing records.

They're much less helpful when you ask questions about the data itself.

What properties exist?

What schemas are associated with those properties?

How are things connected?

Which attributes are sparse?

What can actually be queried?

Developers answer these questions by reading documentation.

AI agents answer them by... mostly guessing.

That didn't feel right.

If you're curious how this idea eventually turned into something concrete, you can take a look at the project itself on GitHub: https://github.com/rush-db/rushdb

That led me to LMPG

Eventually this line of thinking evolved into what I now call Labeled Meta-Property Graphs (LMPG).

Instead of treating properties as hidden key-value pairs attached to records, LMPG promotes them to first-class graph elements. The result is a graph that describes not only the records themselves, but also the structure emerging from the data.

A simple way to think about it is this:

When arbitrary JSON is written into the system, it isn’t just stored as-is. The write process walks through the JSON structure and turns it into a graph:

Each object becomes a node (a record)
Each property key becomes its own node (a meta-property that preserves the property name and its schema)
Values are stored directly on record nodes as normalized flat dictionaries (rows or flat documents), not as separate nodes
Edges connect records to their meta-properties, defining structure and relationships

So instead of having a record with hidden fields, you get an explicit, connected structure where both data and schema are written together at write time.

For example, something like:

{
  "artist": "Metallica",
  "year": 1986,
  "genres": ["thrash metal", "heavy metal"]
}

becomes a structure where:

There is a record node
There are meta-property nodes like artist, year, genres
The actual values ("Metallica", 1986, "thrash metal", "heavy metal") are stored within the record as normalized fields
The graph captures how those properties relate to the record and to each other

This has a few important consequences:

The schema is not predefined, but it emerges and is stored as data is written
Records remain normalized as flat structures (values are not duplicated across separate nodes)
Relationships between records and meta-properties are explicit and traversable
Both humans and agents can introspect the structure directly, without needing external documentation or manual modeling

Originally this wasn't about AI at all.

It was simply an attempt to make arbitrary information explorable without forcing people into rigid schemas.

Only later did I realize another interesting consequence.

If the database already knows which properties exist, how they're structured, and how records relate to each other, then developers and eventually AI agents don't have to rediscover that information over and over again.

More about LMPG model here: https://docs.rushdb.com/learn/records-and-queries/labeled-meta-property-graph

And data write mechanism behind the scenes: https://docs.rushdb.com/learn/records-and-queries/import-data

Then 2024 happened

By 2024, large language models had already become widely adopted for about a year.

And something clicked.

Back then, Collect was already acting as a kind of in-between layer: a lightweight database engine with batteries included, sitting between raw data and application logic. It was quietly serving as a data platform for rapid prototyping, especially for developers and teams who wanted to skip the usual data rituals.

Instead of carefully designing schemas, stitching together backend APIs, and reshaping responses for the frontend, they could just work with what they needed directly.

Store what the frontend needs.

Not what the backend forces you to assemble.

JSON in → JSON out.

That’s how I described it at the time.

And suddenly, that approach started to feel very relevant again.

Because AI agents were running into the exact same friction.

They didn’t want rigid schemas.

They didn’t want to reverse-engineer APIs.

They needed flexible, introspectable data they could reason about directly.

What had once been a convenience for developers started to look like a missing layer for AI systems.

For the first time in ten years, this old project suddenly felt completely at home.

What started as software for collectors had quietly evolved into infrastructure for AI systems.

I definitely didn't plan that.

Looking back

It's funny how one conversation over dinner ended up defining such a big part of my career.

I never set out to build an AI database.

I wanted to help someone stop buying the same CD twice.

Everything else happened because I kept following the same question:

How can humans organize information naturally, while still making it understandable for both people and machines?

Apparently, I'm still trying to answer that question.

If you made it this far and want to explore the idea further, the code and experiments are all available here:
https://github.com/rush-db/rushdb

Backendless Fullstack Development: React useForm + RushDB

Artemiy Vereshchinskiy — Thu, 26 Jun 2025 15:53:48 +0000

TL;DR: This example shows how to build a full-stack application using React Hook Form + RushDB with zero schema setup, backend efforts or data normalization. View the complete source code.

In modern web development, we often spend more time dealing with data modeling, normalization, and database migrations than on the actual business logic that drives our applications. What if we could skip all of that and focus solely on the shape of our data and the user experience?

This article explores how combining React Hook Form with RushDB creates a powerful, backendless approach to fullstack development that eliminates the traditional complexity of working with form data.

The Traditional Form Submission Flow

Let's consider what typically happens when building a form in a web application:

Define database schema/migrations
Create models with proper validation
Build controllers to handle data transformation
Set up services to process business logic
Design a REST API to connect your frontend
Implement API calls from your frontend form
Normalize nested data before storing it

This approach requires maintaining multiple data representations across your stack, writing repetitive boilerplate code, and continuously synchronizing changes between layers. Even with ORMs and other tools, the complexity remains significant.

The Backendless Approach with RushDB

RushDB offers a radically different approach by providing a graph database that:

Accepts any JSON structure directly
Automatically normalizes nested objects into a graph
Requires zero schema setup or migrations
Preserves the exact shape of your data

This means you can take your form data exactly as it is structured in your frontend and store it directly without any transformation or normalization.

Let's See It In Action

Let's examine a comprehensive form implementation using React Hook Form with Zod validation and RushDB for storage.

1. Setting Up RushDB

First, we initialize the RushDB client:

// db.ts
import { RushDB } from "@rushdb/javascript-sdk";

// Initialize RushDB
export const db = new RushDB(env.RUSHDB_API_TOKEN);

That's it! No schema definitions, no models, no complex setup.

You can get a free API token by signing up at app.rushdb.com.
For more information on getting started, see the official documentation.

2. Defining Our Form Schema

We use Zod to define the validation schema for our form:

// Form validation schema
const formSchema = z.object({
  // Personal Information
  firstName: z.string().min(2, "First name must be at least 2 characters"),
  lastName: z.string().min(2, "Last name must be at least 2 characters"),
  email: z.string().email("Invalid email address"),
  phone: z.string().min(10, "Phone number must be at least 10 digits"),
  dateOfBirth: z.string().min(1, "Date of birth is required"),

  // Address Information (nested object)
  address: z.object({
    street: z.string().min(5, "Street address is required"),
    city: z.string().min(2, "City is required"),
    state: z.string().min(2, "State is required"),
    zipCode: z.string().min(5, "ZIP code must be at least 5 characters"),
    country: z.string().min(2, "Country is required"),
  }),

  // Professional Information
  company: z.string().min(2, "Company name is required"),
  position: z.string().min(2, "Position is required"),
  experience: z.enum(["entry", "junior", "mid", "senior", "lead", "executive"]),
  salary: z.number().min(0, "Salary must be a positive number"),
  skills: z.array(z.string()).min(1, "At least one skill is required"),

  // Preferences (nested object with boolean values)
  preferences: z.object({
    newsletter: z.boolean(),
    notifications: z.boolean(),
    publicProfile: z.boolean(),
    dataSharing: z.boolean(),
  }),

  // Additional Information
  bio: z.string().max(500, "Bio must be less than 500 characters"),
  website: z.string().url("Invalid URL").optional().or(z.literal("")),
  linkedIn: z.string().url("Invalid LinkedIn URL").optional().or(z.literal("")),
  github: z.string().url("Invalid GitHub URL").optional().or(z.literal("")),
});

type FormData = z.infer<typeof formSchema>;

Notice how we naturally represent the form data with nested objects and arrays - this matches exactly how we think about the data in our application.

3. Submitting Form Data to RushDB

The most remarkable part is how we handle form submission:

const onSubmit = async (data: FormData) => {
  try {
    // Save to RushDB
    await db.records.createMany({
      label: "FORM_DATA",
      data,
    });

    reset(); // Reset form after successful submission
  } catch (error) {
    // ..
  } finally {
    // ..
  }
};

That's it! Just a single API call to store the entire form data, including nested objects and arrays, without any normalization or transformation.

This image shows the actual network request containing the raw form data that gets sent to RushDB. Notice how the nested structure stays intact with no transformation required.

What's Happening Behind the Scenes?

When you submit the form data to RushDB:

The entire JSON structure is accepted as-is
Nested objects (like address and preferences) are automatically normalized into separate nodes in the graph
Array items (like skills) are stored as a normal Property of FORM_DATA Record
The original structure is preserved for querying later

RushDB handles all the complexity of storing a deeply nested object structure while maintaining the relationships between entities.

The 3D graph visualization shows how RushDB has automatically normalized your form data into a graph structure. Each node represents an entity from your form, and the edges show the relationships between them.

Despite being stored as a graph, RushDB also provides this familiar table view of your data. This makes it easy to query and analyze your data in a familiar way.

Benefits of This Approach

1. Zero Backend Complexity

No need to:

Define schemas or migrations
Create models or DTOs
Build controllers and services
Normalize data manually

2. Preserve Natural Data Structures

Store data in the same shape as your application thinks about it
No need to flatten nested objects
Arrays are handled seamlessly

3. Full-Stack Type Safety

Your Zod schema generates TypeScript types that can be used throughout your application
The same types work for both form validation and data storage

4. Rapid Development

Focus on business logic and UX, not database structure
Iterate quickly without worrying about schema changes
Add new fields without migrations

Querying the Data

One of the most powerful aspects of RushDB is its ability to query this complex data structure easily. For example, finding all form submissions from senior engineers:

const seniorEngineers = await db.records.find({
  labels: ["FORM_DATA"],
  where: {
    experience: "senior",
    position: { $contains: "Engineer" },
  },
});

Or finding all users who have subscribed to the newsletter and have JavaScript skills:

const subscribedJsDevelopers = await db.records.find({
  labels: ["FORM_DATA"],
  where: {
    preferences: {
      newsletter: true,
    },
    skills: { $contains: "JavaScript" },
  },
});

Conclusion

The combination of React Hook Form for frontend validation and RushDB for data storage creates a powerful backendless approach to full-stack development. It allows you to focus on what really matters - the shape of your data and the user experience - without getting bogged down in database schemas, normalization, and complex backend architectures.

This approach is particularly well-suited for:

Rapid prototyping and MVP development
Applications with complex, nested data structures
Teams looking to reduce backend complexity
Projects where the data model is evolving rapidly

By removing the traditional backend complexity, you can build sophisticated applications faster and with less code. RushDB's ability to handle nested JSON structures directly means you can model your data in the most natural way for your application without worrying about how it will be stored.

For more information about RushDB's capabilities, check out the official documentation and explore the examples repository.

Source Code: The complete example from this article is available at github.com/rush-db/examples/tree/main/vite-react-useForm

Introducing RushDB: Zero-Config Instant Database for Modern Apps & AI Era

Artemiy Vereshchinskiy — Sun, 16 Feb 2025 17:53:20 +0000

In today's fast-paced development landscape, managing databases shouldn't slow you down. RushDB is a zero-config, graph-powered instant database designed to streamline data ingestion, normalization, and querying. Built for modern apps, AI, and DS/ML workflows, it offers automatic schema handling, ACID compliance, and a seamless developer experience.

Forget rigid schemas and manual indexing - RushDB lets you push raw JSON or CSV, automatically structures relationships, and optimizes queries on the fly. Whether you're building SaaS, AI models, or large-scale data applications, RushDB accelerates your workflow so you can focus on innovation, not infrastructure.

tldrl;

GitHub Repository

Homepage - rushdb.com

Demo App

Docs

Why RushDB?

Traditional databases slow teams down with complex setup, rigid schemas, and manual optimizations. We've seen firsthand how data management creates unnecessary friction, delaying feature development and forcing engineers to wrestle with infrastructure instead of shipping great products.

RushDB removes these barriers entirely by blending the best of both worlds - the freedom of writing data like MongoDB and the structured flattening of SQL. It automates data normalization, optimizes queries on the fly, and eliminates the need for manual indexing or schema design. The result? A frictionless developer experience that lets you focus on building, scaling, and delivering value—without getting stuck in database operations.

How RushDB Unlocks Developer Productivity

Zero Configuration – Just push any JSON or CSV; RushDB automatically suggests types, normalizes data, and labels relationships - all on the fly.
Graph-Powered Storage – Automatically structures relationships between data.
ACID Transactions – Ensures consistency and reliability.
Powerful Yet Simple Querying – RushDB eliminates the gap between how you perceive data and how you query it, making data retrieval frictionless and natural - so you can focus on shipping products, not syntax.
Self-Hosted or Cloud – Deploy anywhere with ease, or choose RushDB Cloud. Start building in under 30 seconds.
SDK-like DX Even for REST API – Enjoy a seamless developer experience with an intuitive, structured API that feels like an SDK, minimizing boilerplate and complexity.

Use Cases

SaaS & Apps

RushDB is perfect for modern SaaS applications requiring fast, schema-less data ingestion and querying.

AI & ML Research

With its graph-powered structure, RushDB simplifies working with interconnected datasets, making it ideal for AI-driven applications.

IoT & Search Engines

RushDB efficiently stores and retrieves large-scale IoT data and searchable content with built-in indexing.

Key Features

1. Accepts Any JSON, JSONB, and CSV Data

RushDB allows developers to push raw JSON or CSV data without worrying about schema definitions. RushDB automatically normalizes data and structures it as a graph, making queries fast and intuitive.

Create Record

Python:

from rushdb import RushDB

db = RushDB("API_TOKEN")

data = {
    "name": "Google LLC",
    "address": "1600 Amphitheatre Parkway, Mountain View, CA 94043, USA",
    "foundedAt": "1998-09-04T00:00:00.000Z",
    "rating": 4.9
}

record = db.records.create("COMPANY", data)

TypeScript:

const db = new RushDB('API_TOKEN');

const data = {
    name: 'Google LLC',
    address: '1600 Amphitheatre Parkway, Mountain View, CA 94043, USA',
    foundedAt: '1998-09-04T00:00:00.000Z',
    rating: 4.9
}

const record = await db.records.create("COMPANY", data)

Query Records

Python:

query = {
    "labels": ["COMPANY"],
    "where": {
        "name": {"$contains": "Goog"},
        "rating": {"$gte": 4}
    }
}

records = db.records.find(query)

TypeScript:

const records = await db.records.find({
    labels: ['COMPANY'],
    where: {
        name: { $contains: 'Goog' },
        rating: { $gte : 4 }
    }
})

Learn more in the docs

2. Automatic Data Normalization and Type Inference

RushDB takes raw input data and automatically structures it into a connected graph, allowing for seamless navigation across relationships.

Example JSON data

/* ORDER */
{
  "total": 109.98,                           <-- PROPERTY total:`number`
  "status": "processing",                    <-- PROPERTY status:`string`
  "placedAt": "2025-02-15T09:35:26+00:00",   <-- PROPERTY placedAt:`datatime`
  "SHIPPING": {                              <-- RECORD :SHIPPING
    "address": "123 Main St, City, Country", <-- PROPERTY address:`string`
    "method": "express",                     <-- PROPERTY method:`string`
    "cost": 9.99                             <-- PROPERTY cost:`number`
  }
}

Above payload will be automatically normalized into separate flat Records. And relationship between ORDER and SHIPPING will be created automatically.

Learn more in the docs

3. Relationships

RushDB automatically creates relationships between Records based on JSON input, which is normalized into separate flat Records.

However, relationship creation isn't limited to data loading. You can also establish relationships between existing Records, providing a powerful tool to add more meaning to your data.

Managing Relationships:
Python:

project = db.records.create(
    "PROJECT", {"name": "Secret Project", "budget": 1000000}
)

employee = db.records.create(
    "EMPLOYEE", {"name": "Nikola Tesla"}
)

options = RelationshipOptions(type="HAS_EMPLOYEE")

# create Relationship
project.attach(employee, options)

# delete Relationship
project.detach(employee)

TypeScript:

const project = await db.records.create('PROJECT', {
    name: 'Secret Project',
    budget: 1000000
})

const employee = await db.records.create('EMPLOYEE', {
    name: 'Nikola Tesla'
})

// create Relationship
await project.attach(employee, { type: 'HAS_EMPLOYEE' })

// delete Relationship
await project.detach(employee)

Learn more in the docs

4. Query Smarter, Not Harder

Effortlessly find exactly what you need. With automated, on-the-fly data normalization, you can query complex, deeply interconnected data without workarounds or unnecessary overhead - just clear, intuitive access to your data.

Examples

Python:

db.records.find(
    {
        "labels": ["COMPANY"],
        "where": {
            "stage": "seed",
            "address": {"$contains": "USA"},
            "foundedAt": {"$lte": {"$year": 2000}},
            "rating": {
                "$or": [{"$lt": 2.5}, {"$gte": 4.5}]
            },
            "EMPLOYEE": {
                "$relation": {"type": "HIRED", "direction": "out"},
                "$alias": "$employee",
                "salary": {
                    "$gte": 500_000
                }
            },
        },
        "aggregate": {
            "employees": {
                "fn": "collect",
                "alias": "$employee",
                "limit": 10
            }
        },
        "skip": 0,
        "limit": 100
    }
)

TypeScript:

await db.records.find({
  labels: ['COMPANY'],
  where: {
    stage: 'seed',
    address: { $contains: 'USA' },
    foundedAt: {
      $lte: { $year: 2000 }
    },
    rating: {
      $or: [{ $lt: 2.5 }, { $gte: 4.5 }]
    },
    EMPLOYEE: {
      $relation: { type: 'HIRED', direction: 'out' },
      $alias: '$employee',
      salary: {
        $gte: 500_000
      }
    }
  },
  aggregate: {
    employees: {
      fn: 'collect',
      alias: '$employee',
      limit: 10
    }
  },
  skip: 0,
  limit: 100
})

Under the hood, RushDB transforms this into an optimized and powerful Cypher query. The query engine allows developers to think about data naturally, the way we intuitively use and perceive it, while RushDB handles the complexity behind the scenes:

MATCH (record:__RUSHDB__LABEL__RECORD__:COMPANY { __RUSHDB__KEY__PROJECT__ID__: $projectId })

WHERE (any(value IN record.stage WHERE value = "seed"))
AND (any(value IN record.address WHERE value =~ "(?i).*USA.*"))
AND (any(value IN record.foundedAt WHERE apoc.convert.fromJsonMap(`record`.`__RUSHDB__KEY__PROPERTIES__META__`).`foundedAt` = "datetime" AND datetime(value) <= datetime({year: 2000})))
AND ((any(value IN record.rating WHERE value < 2.5) OR any(value IN record.rating WHERE value >= 4.5)))

ORDER BY record.`__RUSHDB__KEY__ID__`
DESC SKIP 0 LIMIT 100

OPTIONAL MATCH (record)-[:HIRED]->(record1:EMPLOYEE) WHERE (any(value IN record1.salary WHERE value >= 500000))
WITH record, record1
WHERE record IS NOT NULL AND record1 IS NOT NULL

WITH record,
apoc.coll.sortMaps(collect(DISTINCT record1 {
    .*, __RUSHDB__KEY__LABEL__: [label IN labels(record1) WHERE label <> "__RUSHDB__LABEL__RECORD__"][0]
}), "__RUSHDB__KEY__ID__")[0..10] AS `employees`

RETURN collect(DISTINCT record {
    __RUSHDB__KEY__ID__: record.__RUSHDB__KEY__ID__,
    __RUSHDB__KEY__PROPERTIES__META__: record.__RUSHDB__KEY__PROPERTIES__META__,
    __RUSHDB__KEY__LABEL__: [label IN labels(record) WHERE label <> "__RUSHDB__LABEL__RECORD__"][0],
    `employees`
}) AS records

Learn more in the docs

5. Transactions

RushDB is fully ACID-compliant, providing robust tools to ensure data consistency and reliability. With the Transactions API, you can execute multiple operations confidently - either every request completes successfully, or all changes are rolled back, maintaining data integrity.

Working with transactions in RushDB is seamless:

Python:

tx = db.transactions.begin()

try:
    # Create some Records
    item = db.records.create(
        "ITEM",
        {"title": "Nike Air Max 270", "price": 150},
        transaction=tx,
    )

    owner = db.records.create(
        "OWNER",
        {"name": "Jane Smith", "email": "janesmith@example.com"},
        transaction=tx
    )

    options = RelationshipOptions(type="OWN", direction="out")

    # create Relationship
    owner.attach(item, options, transaction=tx)

    # Simulate an error
    raise ValueError("Simulated error")

    # Commit the Transaction if all operations succeed
    tx.commit();

except ValueError:
    #  If any records or relationships creation failed, roll back the entire operation
    transaction.rollback()

TypeScript:

const tx = await db.tx.begin();

try {
  // Create some Records
  const item = await db.records.create('ITEM', {
    title: 'Nike Air Max 270',
    price: 150
  }, tx);

  const owner = await db.records.create('OWNER', {
    name: 'Jane Smith',
    email: 'janesmith@example.com',
  }, tx);

  // create Relationship
  await owner.attach(item, {
    type: 'OWN',
    direction: 'out',
  }, tx);

  // Simulate an error
  throw new Error('Simulated error')

  // Commit the Transaction if all operations succeed
  await tx.commit();
} catch (e) {
  // If any Records or Relationships creation failed, roll back the entire operation
  await tx.rollback();
}

Learn more in the docs

6. Properties: Lightweight Connectors That Unify Your Data

Minimal data overhead, maximum impact—RushDB’s Properties system enables developers to build best-in-class search experiences while unlocking deeper insights from their data.

Properties act as intelligent containers that links Records, connecting fields with the same name and type across different data entities. For example, if multiple Records - regardless of Label - share a color property with the value red, RushDB will automatically surface all relevant Records. It’s like querying across multiple SQL tables by a common field and value, but without the complexity.

This makes Properties a powerful tool for data discovery, search, and seamless cross-entity relationships.

Example

Python:

query = {
    "where": {
        "color": "red"
    }
}

records = db.records.find(query)

TypeScript:

const records = await db.records.find({
    where: {
        color: 'red'
    }
})

Moreover, with the Properties API, building advanced search experiences is straightforward. Developers can seamlessly query related Records across different entities without complex joins or manual indexing. Whether you're implementing faceted search, dynamic filtering, or personalized recommendations, RushDB ensures your data remains connected and instantly accessible.

Python:

# Property `name` [string]
db.properties.values(
  "0192397b-8579-7ce2-a899-01c59bad63f8"
)
# Response
{
  "values": [
    "Eleanor Whitaker",
    "Marcus Donovan",
    "Priya Kapoor",
    "Julian Alvarez"
  ],
  "type": "string"
}

# Property \`size\` [number]
db.properties.values(
  "019412c0-2051-71fe-bc9d-26117b52c119"
)
# Response
{
  "min": 5.5,
  "max": 12.5,
  "values": [5.5, 6, 6.5, 7, 7.5, 8, 8.5, ...],
  "type": "number"
}

TypeScript:

// Property `name` [string]
await db.properties.values(
  '0192397b-8579-7ce2-a899-01c59bad63f8'
)
// Response
{
  values: [
    'Eleanor Whitaker',
    'Marcus Donovan',
    'Priya Kapoor',
    'Julian Alvarez'
  ],
  type: 'string'
}

// Property \`size\` [number]
await db.properties.values(
  '019412c0-2051-71fe-bc9d-26117b52c119'
)
// Response
{
  min: 5.5,
  max: 12.5,
  values: [5.5, 6, 6.5, 7, 7.5, 8, 8.5, ...],
  type: 'number'
}

Learn more in the docs

7. A Universal API for the Entire Platform

RushDB is built with a query-centric design, ensuring that most endpoints follow a consistent request format. This unified approach enhances developer experience by minimizing the learning curve - master one request structure, and you can apply it across the entire platform.

At the core of RushDB are three key entities: Record, Property, and Label. All of them can be queried using the same SearchQuery, eliminating the need for backend data gymnastics. This means you can focus on building products without worrying about complex data handling - just query once and get exactly what you need, every time.

Python

# Same DTO to rule them all
query = {
    "where": {
        "$or": [{"stage": "seed"}, {stage: "roundA"}],
        "EMPLOYEE": {
                "salary": {
                "$gte": 500_000
            }
        }
    }
}

# Find Labels of Records that match the criteria
labels = db.labels.find(query)

# Find Records that match the criteria
records = db.properties.find(query)

# Find Properties of Records that match the criteria
properties = db.labels.find(query)

TypeScript:

// Same DTO to rule them all
const query = {
  where: {
    $or: [{ stage: 'seed' }, { stage: 'roundA' }],
    EMPLOYEE: {
      salary: {
        $gte: 500_000
      }
    }
  }
}

// Find Labels of Records that match the criteria
const labels = await db.labels.find(query)

// Find Records that match the criteria
const records = await db.records.find(query)

// Find Properties of Records that match the criteria
const properties = await db.properties.find(query)

8. Powerful Dashboard: Control, Explore, and Query with Ease

RushDB comes with a feature-rich Dashboard that gives you full control over your data, projects, and API access—all in an intuitive, developer-friendly UI. Whether you're a developer or a data-driven team, the dashboard makes exploring and managing your data effortless.

Key Features:

Intelligent Data Querying – A seamless UI that fetches value variations for each filter, enabling precise searches—even for non-developers. Find exactly what you need with sniper precision.
Graph View for Natural Exploration – Visualize relationships the way you think about data, not just how it’s stored. Navigate your graph intuitively, without writing queries.
Project-Based Isolation – Each project is fully self-contained, allowing you to manage multiple independent datasets effortlessly.
Instant Data Import – Upload JSON or JSONB directly from the UI—no coding required. The fastest way to get started and familiarize yourself with RushDB.
SearchQuery Preview – Build queries visually with UI filters and easily reuse the generated configuration in your applications.
More Features Coming Soon! – We're continuously improving the dashboard to make data management even more seamless.

records table view

records graph view

9. Effortless Integration with REST API & SDKs

RushDB offers a powerful, intuitive REST API that seamlessly integrates with your applications. The API is designed with developer productivity in mind, ensuring smooth interaction with your database using minimal code. Whether you're building a complex enterprise app or a lightweight microservice, the provided SDKs streamline operations, offering straightforward methods for creating, querying, and managing your graph data. The SDK-level experience allows developers to effortlessly connect to RushDB via popular programming languages, providing rich documentation and comprehensive examples to minimize friction during integration.

10. Flexible Deployment Options: Cloud or Self-Hosted

RushDB is available in both cloud and self-hosted setups, giving you full control over your infrastructure while ensuring scalability and reliability. With the cloud version, you can quickly deploy and scale your database without worrying about maintenance, offering a fully managed, secure environment. Alternatively, the self-hosted version allows you to run RushDB on your own hardware, giving you the flexibility to customize configurations, maintain complete data control, and integrate with your existing infrastructure.

Conclusion

RushDB empowers developers by combining the best of both worlds—zero-configuration graph databases with best-in-class developer experience. Whether you're working with a cloud or self-hosted setup, RushDB offers unmatched flexibility, scalability, and ease of use, making it the go-to solution for modern applications. With an intuitive REST API and seamless SDK integration, you can focus on building innovative products, leaving the complexities of database management to RushDB.