The indexing works differently (lists are now not unwrapped). The query language is radically different. The history API is via queries and not via an iterator. I don't plan to switch and instead I'll just build new things with 2.0. But 2.0 is not really good-enough because they won't have search plugin (Lucene equivalent) for some time for now. So I don't yet know what to do. IMO it's similar migration as if migrating from Angular 1.x to Angular 2.x -- basically a completely different thing

Also the suggested architectural pattern is different in 2.x. Now they suggest to host it on a separate DB node instead on in-process. I think you'll still be able to do the in-process deploy as Biff does currently but it will just be a different database system. I don't know about their guide for 1.x vs 2.x migration but these are my own observations based on their presentations and my experience with XTDB v1. And I used the internal features at least a bit.

ah these transitions are not nice :( we still have stuff with angular v1 which we will never migrate to v2...

What i read so far the in-process hosting still exists

> What i read so far the in-process hosting still exists Yes but the API is completely different so IMO it's mostly for "new" apps

I liked when v1 didn't need join tables because of the list unrolling. v2 will need to be manually provided with N-M tables (I asked that during the presentation). So not it's less document oriented and more row oriented (even though it's columnar under the hood).

so maybe it would have been better to use a new name for the new product

:man-shrugging: I think it's hard to market two products. Laziness. But well... they kept the bitemporality pattern. But it will be different because tx-fns are different.

@U0BQ9CF8T there's a couple: • to scale them independently, if required. • depending on your typical queries, the XT node may benefit from a different node type to your application - something with better IO, for example. • XT2 benefits more from a longer running server than XT1 does, because of local/memory caching - if you're frequently deploying your application you may have to rebuild the memory cache every time (and maybe the disk cache too, depending on how much of your infra gets recreated on deploy)

Or there could be a snapshot for the DB. Do snapshots make sense if each server would look at a different working set of rows?