Quickstart: choose a sink strategy

The sink connector brings data into Neo4j from Kafka: something else produces messages, and you want them in the graph. Which strategy you use depends on the shape of those messages and how much write logic you need. Each quickstart below is self-contained and runnable on a local Docker stack.

If you want the other direction — Neo4j changes published out to Kafka — see Quickstart: choose a source strategy.

Sink: getting Kafka messages into Neo4j

Your situation Strategy Quickstart

You control the target graph model and need real write logic — derived values, conditionals, several clauses per message.

Cypher — your Cypher statement, run per message.

Sink with Cypher

Your messages map onto nodes and relationships field-for-field, and you would rather declare the mapping than write a query.

Pattern — a Cypher-like pattern per topic; the connector generates the MERGE.

Sink with Pattern

Each message already states its own intent, and deletes are part of the stream.

CUD — every message carries an op field.

Sink with CUD

The messages were produced by Neo4j — a source connector or Neo4j Streams — and you are replicating into another database.

Change Data Capture — change events reapplied to the target.

Sink with CDC

The Sink with CDC guide runs both directions at once, since it replicates one Neo4j database into another.

If two of those look plausible, the tie-breakers are usually:

  • Pattern vs Cypher — can you express the mapping without computing anything? Pattern only maps; it cannot derive a value or branch.

  • CUD vs Pattern — does the operation vary per message? Pattern always upserts. Pattern is also limited to one mapping per topic, whereas CUD carries any label or relationship type on one topic.

  • CDC vs anything else — did the messages come from Neo4j? If not, CDC is the wrong answer; it expects a specific event format and header.

What every quickstart assumes

All of them run the same local stack — Neo4j, a Kafka broker, Kafka Connect and Schema Registry via Docker Compose — and differ only in connector configuration and message shape. So it is reasonable to work through one, then swap the connector to try another.

Serialization differs by strategy, and it is the detail most likely to trip you up:

Strategy Serialization

Cypher, Pattern, CUD

Plain JSON works, so no Schema Registry is needed and messages can be produced by hand with kafka-console-producer.

Change Data Capture

Needs a schema-carrying converter and messages produced by a real source connector. Change events cannot be written by hand.

Where a schema is required, these guides use JsonConverter with schemas.enable=true, which embeds the schema in each message and needs no Schema Registry. Avro and Protobuf are covered on each page, and in Schema Registry.

Deploying somewhere other than Docker

The strategy guides use a local Docker Compose stack so they can be run start to finish. The strategy configuration is identical wherever you deploy it — only installation and connection details change: