The relational data model is now more than 40 years old. It's good for very diferent scenarios and can handle certain types of data very well. But it isn't perfect. An increasing number of non-relational systems are being worked on, collectively called the 'NoSQL movement'. NoSQL is an umbrella term for a loosely defined class of non-relational datastores and best described as 'Not only SQL'. Examples are Google's BigTable and Amazon's Dynamo. These systems may provide advantages over relational databases, but generally lack the relational robustness for those advantages. In an atempt to modestly contribute to the current research in the field of geographical information systems, this research reports on a comparison of one such NoSQL datastore called Neo4j with the traditional relational database PostgreSQL when storing and querying spatial vector data. The goal of this study was to determine whether a traditional relational database system like PostGIS, or a NoSQL system, such as Neo4j-Spatial, would be more efective as the underlying technology for operating OpenStreetMap data. Neo4j is an embeddable graph database. Embeddable because it can be added to a Java-based application and used just like any other library, and graph database because the data model it uses to express its data is a graph, storing nodes and relationships that connect them, supporting user defined properties on both constructs. Multiple aspects are of interest when comparing spatial database systems. The evaluation methodology designed to compare the two, involves both objective measurements and subjective measurements based on documentation and experience. The objective tests include processing speed based on a predefined set of queries, disk space requirements, and scalability. Subjective tests include maturity/level of support, stability and ease of use. Meanwhile, the assessment framework applied for the objective tests could be used as a test suite for evaluating the performance and reliability of new spatial datastores. A test environment have been created using the same OpenStreetMap data in both the graph database and the relational database. While the systems have fundamental diferences, identical operations have been developed that provides equal results from diferently sized study areas. Regarding the objective measurements, the results of this research show that the graph database is most beneficial when queries can be expressed as traversals over local regions of a graph. Queries that are well-suited to this approach are, for example, shortest path analyses or connectivity queries. Bounding box queries were faster on the relational database. Regarding the subjective measurements, Neo4j provides a lot of functionality. Transaction support is a welcome addition and there are numerous ways to execute queries, for instance using Java, CQL or a geopipeline. The database model is schema-less and allows additions or adjustments to the schema without any major impact on the data model. As a Java component, it is relatively easy to implement Neo4j-Spatial as an embedded component in any Java program. PostgreGIS is by far the more mature database with a lot of functionality, documentation and support. Overall, this research shows that, in some cases, Neo4j should be considered as an alternative for specific tasks. A buyer's guide has been created in the form of a fow diagram to decide whether Neo4j- Spatial or PostGIS is suitable for a project. The two technologies, relational databases and non- relational database, will remain in usage side by side, each with the perfect fit for its own capabilities.