We have noticed some performance issues after migrating from Neo4j version 4 to version 5.
I have reviewed the indexing, and it appears to be the same as before.
Could you please suggest any solutions or steps we can follow to improve performance and optimize the overall application?
Thank you in advance for your assistance.
are there any further details
is there any detail of how much performance decreased? i.e. under 4.4.5 the query ran in 100ms but under 5.26.0 it ran in ??? ms?
did you migrate to block format? Store formats - Operations Manual ?
Hi @dana_canzano, I'm not entirely sure about the exact timing, as it varies depending on the queries. For example, queries that previously took around 100ms are now taking approximately 150ms, and those that took 1.2s are now taking around 2.5s.
During the migration process, I took a dump from the older version of the database and simply imported it into the newer version. I also updated the Neo4j driver package to the latest version for Node.js (v5.28.0).
So, if I'm not mistaken, it's performing a default block format migration.
cypher statement
show DATABASE yield name, store;
will report the database name and record format. Does this report block?
I ran the following Cypher query to check the database configuration:
SHOW DATABASES YIELD name, store;
The result shows that both the neo4j and system databases are using the record-aligned-1.1 store format, which is expected and aligns with the standard format used in Neo4j 5.x.
╒════════╤════════════════════╕
│name │store │
╞════════╪════════════════════╡
│"neo4j" │"record-aligned-1.1"│
├────────┼────────────────────┤
│"system"│"record-aligned-1.1"│
└────────┴────────────────────┘The result shows that both the
neo4jandsystemdatabases are using therecord-aligned-1.1store format, which is expected and aligns with the standard format used in Neo4j 5.x.
ok. but this is in contrast to your prior comment of
Yes, you're right — I made a mistake in my earlier comment as I wasn’t fully aware of the store format details at that time.
Now that I understand it better, I’d like to clarify — is the store format actually contributing to the performance issue we’re seeing?
Also, could you please advise whether using the store type block format (if available) would be more efficient, or is the current record-aligned-1.1 format already the most optimal in terms of performance?
I’d appreciate your suggestion on this so we can explore any potential improvements.
You shouldnt have to migrate to block as performance from v4 to v5 should be equivalent if not better. However moving to block may introduce better performance.
So back to why is v4 'faster' than v5? Do you still have the v4 environment available such that you could compare.
a. conf/neo4j.conf setting, specifically related to `dbms.memory*`
or `server.memory*`
b. can you preface a know query with performance concerns
with `PROFILE` and compare the query plans?
@dana_canzano I tried changing the database store format from "aligned" to "blocks" in my local environment, but I didn’t observe any significant improvement in query performance. Also, I currently don’t have access to a v4 environment—otherwise, I would have tested it there as well.
Hi @dana_canzano ,
While upgrading the database version, I also updated the Neo4j driver to the latest version. My project uses GraphQL as well, and I'm currently running it on Node.js v16.4.2.
I’m wondering—could the issue be related to the older versions of the GraphQL-related packages? Here’s what I’m currently using:
"express-graphql": "^0.12.0",
"graphql": "^14.7.0",
"graphql-tools": "^7.0.1",
"neo4j-driver": "^5.28.0",
"neo4j-graphql-js": "^2.14.3"
Is it possible that this version mismatch—especially with the older GraphQL libraries—might be contributing to the issue?
Did you create constraints and indexes in 5.28 version? You can check it by running this: SHOW CONSTRAINTS or SHOW INDEXES. Results shows all the indexes/constraints.
Hi @ameyasoft ,
I’ve already checked the indexing and constraints, and everything appears to be in place. I didn’t need to create them manually—they were automatically created when I imported the old dump into the Neo4j v5 database. All indexes follow the new format (e.g., range and text), so I don’t believe there’s any issue on that front.
Additionally, I compared the same query on both the old and new databases and found that the new database actually executes the query faster. However, the final response in the application seems slower.
I'm starting to suspect that this may be due to the older version of GraphQL being used in the project, which I haven’t updated during the migration from Neo4j v4 to v5.
Is it possible that the new Neo4j driver isn't fully compatible with the older GraphQL version, and that’s what’s affecting performance?
For more context on the package versions, please refer to my previous messages in this thread.
Hi @ameyasoft and @dana_canzano, just following up on my previous query as I haven’t received any response yet.
Would really appreciate any guidance or suggestions from the community.
Please let me know if anything is unclear or if I need to provide more details.