PlatformChart

	eXist	MarkLogic	Sausalito	BaseX
Open upgrade path (future versions not closed to us)	✓	?	?	✓
Handles multiple data sources	✓	✓	✓	✓
Documentation available and sufficient	✓	?	✓	✓
Decoupled interface development	✓	✓	✓	✓
Security handling	?	?	?	?
Ease of installation and use	test	test	test	test
Talks to Oxygen	✓	✓	x	± [2]
Agnosticism re: location	test	test	test	test
REST support	✓	✓	✓	✓
Native Red Hat	x	± [1]	± [3]	v. 6
Ease of update	✓	ask	ask [4]	ask
Backup and restore	✓	✓	[6]	✓
General performance	ask/test	ask/test	ask/test	ask/test
Flexible deployment (web server, servlet, etc.)	✓	?	✓ [5]	✓

? = need to investigate

test = need to test ourselves

ask = ask on lists, ask our friends

[1] = Yes, but teller, and probably penn, will need more RAM and more disk space to run this.

[2] = Not supported by a special-purpose well-documented interface, but can be done via WedDAV and XQJ. SyncRO has posted brief instructions, and plans to create a how-to guide. For details see this thread (for some reason the 1st post is missing).

[3] = No, but doesn’t matter --- we’d be running it on 28msec, anyway.

[4] = "Updates" in this case would refer primarily to the API provided by 28msec, since all the data (and methods for interacting with it) are cloud-based. There is a desktop client provided, but since their API is fully REST-ful I don't believe you're tied to using it. 28msec seems to update the client software every ~2-4 months from what I can tell.

[5] = Since there isn't any local deployment of the data store itself, pretty much any deployment (as long as it supports standard HTTP protocols) is possible.

[6] = Sausalito applications are deployed to AWS, with backup/restore being part of Amazon's platform/services -- e.g. pretty much built in. I haven't heard of anyone permanently losing data on AWS (which doesn't mean it can't happen).