RushDB vs Pinecone: relationships vs flat vectors.

Side by side

The same task in both: store searchable order notes with business context.

Both snippets make order text semantically searchable. The difference is where the customer, order, and plan context lives — inside the same query, or in a second system your application reconciles.

from pinecone import Pinecone

pc = Pinecone(api_key='YOUR_API_KEY')

# Index config is fixed at creation: model, cloud, region
pc.create_index_for_model(
    name='orders',
    cloud='aws', region='us-east-1',
    embed={'model': 'llama-text-embed-v2',
           'field_map': {'text': 'chunk_text'}},
)

index = pc.Index('orders')
index.upsert_records('ns1', [
    {'_id': 'ord-1', 'chunk_text': 'Annual plan upgrade',
     'category': 'billing'},
])

# The customer, order, and plan records live in another
# database — your app joins them after retrieval.

from rushdb import RushDB

db = RushDB('RUSHDB_API_KEY')

db.ai.indexes.create({'label': 'ORDER', 'propertyName': 'summary'})

# Records, relationships, and searchable text in one write
db.records.import_json(
    label='CUSTOMER',
    data={
        'name': 'Acme',
        'tier': 'enterprise',
        'ORDER': [{'summary': 'Annual plan upgrade',
                   'category': 'billing'}],
    },
)

results = db.ai.search({
    'labels': ['ORDER'],
    'propertyName': 'summary',
    'query': 'plan changes',
    'where': {'CUSTOMER': {'tier': 'enterprise'}},
})

Switching

Moving from Pinecone: collapse the vector store + database pair.

Teams rarely leave Pinecone because similarity search fails — they leave because the architecture around it grows: a vector store, a database of record, and application code joining the two after every retrieval. The migration is mostly consolidation: metadata becomes typed, filterable properties, and the joins your app maintained become relationships.

Who this is for

Pick the right tool for the job.

If your workload is purely similarity ranking over a large, flat vector set — recommendations, document search, dedup — Pinecone’s serverless infrastructure and published scale numbers are a strong, proven choice. If your agent memory needs connections between records (a decision linked to an account, a document linked to its citations), RushDB avoids rebuilding those joins in application code.

Comparison table

Data model, deployment, and pricing

Pinecone rows below are sourced from Pinecone’s own docs and pricing page, checked on the date shown. Two rows are absence findings (nothing found in Pinecone’s docs) rather than an explicit denial from Pinecone — flagged as such.

Pinecone facts sourced from pinecone.io and docs.pinecone.io as of the dates shown above; the Pinecone snippet follows its documented quickstart shape. Two rows above are absence findings (nothing found in Pinecone’s docs), flagged as such rather than treated as a denial. RushDB facts are drawn from RushDB’s own docs and feature pages linked throughout this site. Report a stale claim to hi@rushdb.com.

Implementation example

Store connected memory and recall it by meaning

The relationship between records comes from the write path — no separate join step after retrieval.

from rushdb import RushDB

db = RushDB("RUSHDB_API_KEY")

db.ai.indexes.create({
    "label": "MEMORY",
    "propertyName": "output",
})

db.records.create(
    label="MEMORY",
    data={
        "agent_id": "agent-42",
        "kind": "decision",
        "output": "Keep the free plan, but increase Pro onboarding limits after launch feedback.",
        "status": "approved",
    },
)

recall = db.ai.search({
    "labels": ["MEMORY"],
    "propertyName": "output",
    "query": "What did we decide about Pro onboarding?",
    "where": {"agent_id": "agent-42", "status": "approved"},
    "limit": 5,
})

print(recall.data)

Questions developers ask.

Related

Go deeper on the workflow.