Need advice about which tool to choose?Ask the StackShare community!
Elasticsearch vs PostGIS: What are the differences?
Introduction
Elasticsearch and PostGIS are both popular tools used for managing and analyzing large amounts of data. However, they have some key differences in terms of functionality and purpose. In this article, we will explore and compare these differences.
Data Structure: Elasticsearch is a search engine that uses a flexible and schema-less JSON-based data structure. It is designed to handle unstructured and semi-structured data efficiently. PostGIS, on the other hand, is an extension of PostgreSQL that adds support for geographic objects. It allows storing and querying spatial data using various geometric and geographic data types.
Querying Capabilities: Elasticsearch offers advanced full-text search capabilities, supporting complex queries including fuzzy search, wildcard search, and phrase matching. It also provides relevance scoring to rank search results based on relevance. PostGIS, however, focuses on spatial queries and offers a wide range of spatial operators and functions to perform spatial analysis and calculations.
Scalability and Distribution: Elasticsearch is built from the ground up to be distributed and scalable. It allows horizontal scaling by adding more nodes to the cluster, enabling data to be distributed across multiple machines. It also provides built-in replication and sharding mechanisms for high availability and performance. PostGIS, on the other hand, is primarily designed as a single-node database system and does not offer native support for distributed architectures.
Indexing and Data Storage: Elasticsearch uses an inverted index for efficient full-text search. It automatically indexes every field in a document, making it suitable for fast text-based searches. PostGIS uses a B-tree index for efficient querying of spatial data. It supports both spatial and non-spatial indexing, allowing for efficient retrieval of specific spatial objects or attribute values.
Data Modeling: Elasticsearch allows for dynamic data modeling, meaning that fields and data types can be modified on-the-fly without requiring a predefined schema. This flexibility is suitable for scenarios where the data structure is not known in advance or frequently changes. PostGIS, however, requires a predefined table schema and is more suitable for scenarios with a fixed or predictable data structure.
Integration and Ecosystem: Elasticsearch has a rich ecosystem with various plugins and integrations available. It seamlessly integrates with other tools like Logstash and Kibana for log analysis and visualization. It also provides APIs and libraries for easy integration with different programming languages. PostGIS, being an extension of PostgreSQL, benefits from the vast ecosystem and features of the PostgreSQL database, including transaction support, user management, and support for other data types.
In summary, Elasticsearch is a search engine designed for full-text search and scalable, distributed data processing, while PostGIS is an extension of PostgreSQL specifically tailored for spatial data management and analysis.
Hey everybody! (1) I am developing an android application. I have data of around 3 million record (less than a TB). I want to save that data in the cloud. Which company provides the best cloud database services that would suit my scenario? It should be secured, long term useable, and provide better services. I decided to use Firebase Realtime database. Should I stick with Firebase or are there any other companies that provide a better service?
(2) I have the functionality of searching data in my app. Same data (less than a TB). Which search solution should I use in this case? I found Elasticsearch and Algolia search. It should be secure and fast. If any other company provides better services than these, please feel free to suggest them.
Thank you!
Hi Rana, good question! From my Firebase experience, 3 million records is not too big at all, as long as the cost is within reason for you. With Firebase you will be able to access the data from anywhere, including an android app, and implement fine-grained security with JSON rules. The real-time-ness works perfectly. As a fully managed database, Firebase really takes care of everything. The only thing to watch out for is if you need complex query patterns - Firestore (also in the Firebase family) can be a better fit there.
To answer question 2: the right answer will depend on what's most important to you. Algolia is like Firebase is that it is fully-managed, very easy to set up, and has great SDKs for Android. Algolia is really a full-stack search solution in this case, and it is easy to connect with your Firebase data. Bear in mind that Algolia does cost money, so you'll want to make sure the cost is okay for you, but you will save a lot of engineering time and never have to worry about scale. The search-as-you-type performance with Algolia is flawless, as that is a primary aspect of its design. Elasticsearch can store tons of data and has all the flexibility, is hosted for cheap by many cloud services, and has many users. If you haven't done a lot with search before, the learning curve is higher than Algolia for getting the results ranked properly, and there is another learning curve if you want to do the DevOps part yourself. Both are very good platforms for search, Algolia shines when buliding your app is the most important and you don't want to spend many engineering hours, Elasticsearch shines when you have a lot of data and don't mind learning how to run and optimize it.
Rana - we use Cloud Firestore at our startup. It handles many million records without any issues. It provides you the same set of features that the Firebase Realtime Database provides on top of the indexing and security trims. The only thing to watch out for is to make sure your Cloud Functions have proper exception handling and there are no infinite loop in the code. This will be too costly if not caught quickly.
For search; Algolia is a great option, but cost is a real consideration. Indexing large number of records can be cost prohibitive for most projects. Elasticsearch is a solid alternative, but requires a little additional work to configure and maintain if you want to self-host.
Hope this helps.
When I found out how powerful PostGIS was, I was gobsmacked. No matter how ridiculous that sample data I'd provide, the results would be fast and come back accurate and consistently.
The only other database engine that offered decent GIS indexing and searching, was ElasticSearch. But ES is not an ACID adhering engine, and is specifically designed to be a screaming fast fulltext search engine first, and everything else second. You never want ES to be your primary database engine (it's not designed for that anyways), it should always be a compliment to your more stable and consistent database solution.
Simply put, I could have stuck to a MySQL + ElasticSearch solution, but the operating costs around that get astronomical when you get down to ho HEAVY ElasticSearch is, and how expensive it is to operate in the any hosting solution.
PostGIS allows to me not need ES for geospatial indexing and querying, and to be really fast at it while doing it. A god send.
Pros of Elasticsearch
- Powerful api328
- Great search engine315
- Open source231
- Restful214
- Near real-time search200
- Free98
- Search everything85
- Easy to get started54
- Analytics45
- Distributed26
- Fast search6
- More than a search engine5
- Great docs4
- Awesome, great tool4
- Highly Available3
- Easy to scale3
- Potato2
- Document Store2
- Great customer support2
- Intuitive API2
- Nosql DB2
- Great piece of software2
- Reliable2
- Fast2
- Easy setup2
- Open1
- Easy to get hot data1
- Github1
- Elaticsearch1
- Actively developing1
- Responsive maintainers on GitHub1
- Ecosystem1
- Not stable1
- Scalability1
- Community0
Pros of PostGIS
- De facto GIS in SQL25
- Good Documentation5
Sign up to add or upvote prosMake informed product decisions
Cons of Elasticsearch
- Resource hungry7
- Diffecult to get started6
- Expensive5
- Hard to keep stable at large scale4