Recientes avances en Postgres han propulsado la base de datos a entornos donde debe enfrentarse a los retos tecnológicos de hoy en día. En algunas de las compañías más grandes del mundo, PostgreSQL juega un papel esencial en el control del coste y en la reducción de la dependencia de los proveedores tradicionales.
Juan Zamora abordará los siguientes puntos:
* Qué cargas de trabajo son las más apropiadas para la introducción de Postgres en su entorno
* Las métricas que se deben tener en cuenta para evaluar el 'cuándo y cómo' de la expansión de las instalaciones de Postgres
* Avances claves en las últimas versiones de Postgres que soportan nuevos tipos de datos y permiten afrontar nuevos retos
Mi nombre es Juan Zamora, soy el responsible comercial para EDB en el área sur de Europa y Latinoamérica, y la parte principal de mi pasado profesional lo he pasado trabajando en compañías que tenían su foco principal de negocio alrededor de tecnologías Open Source, y en base a este pasado puedo deciros que muchas de las razones que han motivado a las empresas a pasar de Unix a Linux, son las mismas razones que tienen ahora para realizar el mismo movimiento, esta vez, desde carísimos gestores de bases de datos hasta alternativas de fuente abierta.
Existen otros temas a los que prestar atención mientras se recorre este camino, por supuesto pensamos que Postgres puede solventar muchos de los problemas y retos a los que se enfrenta la IT actual, y fundamentalmente de ésto será de lo que hablemos durante el seminario de hoy.
Aunque hablaré sobre productos y soluciones específicas proporcionadas por EDB, el ánimo del webcast de hoy no es dar una charla comercial, si no que queremos plantear un escenario basado en nuestra experiencia y en el feedback de numerosos clientes en el que hablemos sobre lo que las compañías que trabajan con nosotros están haciendo para hacer frente a los retos que se les presentan en la actualidad. A continuación, entraré en detalle sobre dónde estamos viendo despliegues de Postgres y cómo las compañías están midiendo el éxito de las implataciones para, paso a paso, continuar caminando en el proceso de añadir flexibilidad, reducir y diversificar costes, además de establecer las bases para futuras necesidades relacionadas con los datos.
Continuaré hablando sobre cuáles son nuestras recomendaciones sobre cómo empezar a trabajar con nosotros, también mencionaremos algunos datos de contexto sobre EDB y daremos algunos ejemplos sobre lo que estamos haciendo con algunos clientes a nivel mundial. Por último mencionaré las diferencias entre nuestra propuesta empresarial y la versión Open Source, y después dejaré algún tiempo para responder las consultas que pudieran surgir.
Todos hemos escuchado el dicho de que la única constante es el cambio, verdad? Yo estoy plenamente de acuerdo, pero también me gustaría decir que en algunos sitios los cambios llevan más tiempo que el que desearíamos. Y uno de esos sitios es el escenario de las bases de datos
La mayoría de las empresas continúan hoy día haciendo frente a iniciativas de redución de costes. Hace una década, estos retos estaban relacionados con la explosión de la burbuja de las punto com. Ahora acabamos de pasar, si se me permite, la peor crisis financiera de nuestra vida. Desde la perspectiva de IT, podemos apreciar que mientras que los presupuestos se mantienen estables, planos o en franco descenso año tras año, el coste del software de infraestructura se incrementa también de manera constante, y no son costes superfluos de los que se pueda prescindir, es el coste del software que mantiene el sistema activo, el que permite que los procesos se mantengan vivos. De hecho, el coste de las bases de datos es tipicamente es la mayor partida dentro de cualquier presupuesto de software. Esto significa finalmente que no hay suficiente dinero para invertir en el futuro, es decir, en aquellos proyectos que permitan a sus compañías ser más competitivos y en definitiva a crecer.
Por qué las bases de datos son tan caras? Se preguntarán muchos de ustedes… pues bien, la respuesta es que cada base de datos utiliza su propio lenguaje, así que cuando alguien escribe una aplicación y la escribe para una base de datos específica, Oracle, SQL Server, la aplicación está estrechamente acoplada a esa base de datos, haciendo que sea extremadamente difícil de mover, lo que implica que las compañías de bases de datos puedan cobrar lo que realmente quieran, saben que les tienen cautivos.
Pero ahora estamos presenciando un cambio muy importante, las empresas se están dando cuenta de que no pueden pagar las cantidades que les exigen por Oracle, DB2 o SQL Server y para lograr un cambio real, hay que pensar de manera diferente.
Lo que nuestros clientes realmente buscan va más allá del ahorro de costes. Por supuesto, la reducción del gasto es un asunto crítico, pero existen otros costes asociados que también representan una parte importante del presupuesto. Por ejemplo, no se debe despreciar el coste de recursos humanos y el coste en tiempo asociado a la implantación de nuevos proyectos de software que puedan ser inicialmente baratos pero difíciles de implementar, o para los que no existe suficiente conocimiento interno
Lo que también buscan las compañías son soluciones software que son fáciles de utilizar y que proporcionen flexibilidad a la hora de elegir el proveedor de servicios o herramientas de gestión asociadas, pero sobre todo, que tengan un ecosistema maduro alrededor, es decir organizaciones que proporcionen estabilidad tecnológica y empresas que proporcionen el soporte y los servicios necesarios para garantizar el éxito del proyecto.
Con esta combinación de factures, las compañías pueden de veras optimizar su infraestructura y su organización con Open Source
El movimiento desde el costoso software propietario al más económico software libre, no es nada nuevo. Durante la última década hemos asistido a migración generalizada desde Unix a Linux. Linux nos proporcionó tecnología “suficientemente buena” a una fracción del coste que suponía Unix. Pero también nos dió la confianza necesaria para ponerlo en producción a través del hecho de disponer de una comunidad de desarrolladores cuyo objetivo principal era la de incoporar mejoras tecnológicas para convertir el “suficientemente bueno” en tecnología de categoría empresarial, capaz de superar a su antecesor en numerosos ámbitos. Se logró configurar un círculo vicioso muy beneficioso para el desarrollo de la tecnología Open Source, la adopción de la tecnología en un ámbito comercial alimentó económicamente a la comunidad, y la rápida capacidad de innovación de la comunidad, mejoró notablemente las posibilidades de éxito de las distribuciones comerciales. Hemos asistido a otras migraciones similares desde Weblogic o WebSphere a soluciones Open Source. Y ahora somos testigos del movimiento de la tercera pata del software de infraestructura desde bases de datos poco flexibles y enormemente caras a soluciones basadas en software libre, como Postgresql.
Ahora veamos cuál es la tecnología que está liderando ese cambio y para ello vamos a fijarnos en informes realizados por entidades independientes. Por ejemplo DB-ENGINES realiza una clasificación de las bases de datos en cuanto a popularidad utilizando diferentes fórmulas. Por ello sabemos que Postgres es una de las bases de datos más implantadas en el mundo, de hecho se incluye con todas las distribuciones de Linux, pero también es descargada varios millones de veces al año, es muy popular en términos de búsquedas en internet, existe un enorme número de ofertas de trabajo que requieren de sus conocimientos y muchos otros factores. También afirma que Postgres es la segunda base de datos de mayor crecimiento en 2013, lo que prueba que las compañías están migrando a la alternativa Open Source. También es fascinante el hecho de que las otras dos bases de datos en el top 3 sean bases de datos NoSQL, Mongo y Cassandra, lo que abunda en nuestra afirmación de que el mercado busca nuevas formas de trabajar.
Quizás la característia que más diferencia a Postgres de otras bases de datos Open Source alternativas es fundamentalmente su madurez. Postres proviene de Ingres, que nace en la universidad de Berkeley, de hecho hereda su nombre. Cuando a partir de Ingres se crea Ingres Corporation, el proyecto original pasa a llamarse Post-ingres, y cuando sale a la comunidad de la mano de Bruce Monjian, responsible de la comunidad de desarrolladores de Postgres y empleado de EnterpriseDB, pasa a llamarse Posgresql, Postgres para los amigos.
Esta madurez nos diferencia también de otras tecnologías open source, como por ejemplo Linux, que en las fechas donde se comenzó la incorporación a entornos productivos, adolecían de determinadas características que hoy nos parecen esenciales. Era, como ya hemos dicho antes, “suficientemente bueno”. Pues bien, Postgres es una tecnología que lleva más de 30 años en constante proceso de depuración y mejora, y garantiza “Cero problemas” en producción.
Lo que queremos indicar con esta slide, es que Postgres comparte con la mayor parte de bases de datos comerciales del mercado actual, como SQL Server, Sybase, Informix o Ingres, las mismas características que la definen y que la hacen idónea para ser utilizada en entornos críticos. Quizás la más importante de todas ellas es que es ACID, y por tanto totalmente orientada a garantizar la salud del dato y la transaccionalidad.
Los se han dedicado a esta profesión durante algunos años, sabrán que cada cierto tiempo aparece una nueva tecnología que va a reemplazar a las bases de datos relacionales, y ésto ha venido siendo así durante más de 20 años. Lo que acaba ocurriendo es que los fabricantes de bases de datos toman nota de las nuevas tecnologías, la evalúan y si son suficientemente buenas y están en sintonía con lo que los clientes desean, se incorpora a las bases de datos relacionales. Hemos sido testigo de cómo funcionalidades orientadas a objetos en los 90, y xml hace 10 años han pasado a formar parte de las bases de datos relaciones y hoy día es difícil encontrar compañías excclusivamente centradas en objetos o xml….
Este razonamiento continúa siendo válido con NoSQL. La demanda por hacer cosas diferentes generan nuevos componentes tecnológicos, que si son aceptados por el mercado y tiene sentido su adaptación a entornos relacionales, serán incoporados.
El ejemplo de Postgres sigue siendo aplicable para esta tecnología y ha incorporado numerosas funcionalidades durante los últimos años que posiblemente no conozcan, por ejemplo pueden con JSON pueden utilizar Postgres como una base de datos orientada a documentos, y con HSTORE pueden utilizarla como una base de datos orientada a clave valor.
Con los foreing data wrappers, cualquier fuente de datos residente en otra base de datos será vista como una tabla más de la base de datos sobre la que se puede leer y escribir, y el conector de Postgres Plus Advanced Server para Hadoop, permite hacer consultas contra Hadoop desde Postgres Plus y escribir de nuevo en el repositorio Hadoop.
Al final, el mercado motiva nuestra evolución y son los clientes los que nos mueve allá donde existe interés.
Éstas son las fuerzas que están dando forma al futuro de Postgresql:
Por un lado están las pequeñas aplicaciones, aplicaciones web y desarrolladores de aplicaciones que necesitan facilidad de uso y de despliegue
Por otro lado tenemos las grandes aplicaciones empresariales que necesitan funcionalidad avanzada, seguridad, escalabilidad y alta disponibilidad para aplicaciones de misión crítica
Postgres ocupa el área media entre ambos extremos y gradualmente se ha ido expandiendo en ambas direcciones.
Por otro lado la aparición de nuevos tipos de aplicación o de carga de trabajo moldearán las futuras necesidades de los clientes y requerirán, tal y como dice Gartner, que las bases de datos adopten estas nuevas capacidades para satisfacer estas nuevas demandas.
Estos son los tres segmentos de mercado en los que continuaremos invirtiendo para garantizar el éxito de Postgres.
Tal y como avancé anteriormente, es importante ser capaz de ver hacia dónde va nuestra tecnología. Lo está haciendo en la misma dirección en la que usted va? De hecho, sabe su compañía o proyecto hacia dónde va realmente? Si va a invertir en nuevas maneras de llegar al mercado, consideramos que es muy importante conocer cuál es la visión de sus socios tecnológicos y cómo la van a llevar a cabo.
Los siguientes pasos que vamos a dar en la expansión de la funcionalidad de Postgres en esas tres áreas son las siguientes:
El el área de facilidad de uso vamos a mejorar en el diagnóstico de problemas, vamos a trabajar para que la configuración por defecto esté optimizada para el caso más común de uso, vamos a hacer aún más simple la tarea de instalación y vamos a buscar oportunidades para ser la base de datos preferida en la nube
El el área empresarial vamos a seguir trabajando para aprovechar todos los recursos de la máquina y hoy día no es insusual encontar máquinas con 256 procesadores
También vamos a continuar invirtiendo en el escalado horizontal. Éste suele ser un problema muy importante en general, pero para la nube en particular. Ya hemos arrancado iniciativas de investigación que están a punto de ver la luz a nivel empresarial.
Otro apartado importante para las empresas son los diagnósticos, como también lo son para usuarios menos exigentes, es un problema general que vamos a solventar.
En el apartado de NoSQL/New SQL no pretendemos abordar todos los casos, pero pensamos que debemos integrarnos con todas las tecnologias y trabajar con los nuevos tipos de datos, ya que por lo general las infraestructuras de big data no son islas y tienen múltiples conexiones con otros apartados donde es necesario contar con una base de datos relacional.
Esencialmente, se puede hace mucho más con Postgres de lo que se hubiera imaginado y allá donde pudiera estar pensando en utilizar otra tecnología, puede utilizar Postgres como punto común de conexión con datos almacenados en otro lugar.
Ahora veamos cómo trabajamos con nuestros clientes, hablaremos de cargas de trabajo óptimas para Postgres.
Las capacidades añadidas de Postgres que acabo de describir significan más que la posibilidad de contener sus costes sin sacrificar funcionalidades o rendimiento. Echémos un vistazo a cómo y por qué los costes asociados a las bases de datos crecen tan rápidamente. Si se firma un Enterprise License Agreement no debe preocuparse por los costes de la base de datos durante cierto tiempo, lo cual está muy bien, pero nunca hay que perder de vista que los ELA se refieren a un número de licencias objetivo, entonces lo que suele ocurrir es que se despliegan muchos más cores de los que inicialmente se estimaban y este hecho puede conducir a notables dificultades cuando se vaya a renovar el ELA. Lo que realmente distorsiona el número no son las nuevas aplicaciones que vayan a desplegarse, si no más bien las renovaciones hardware, es decir, máquinas que se renuevan cada 4 o 5 años por lo general incorporan el doble número de procesadores que la máquina que van a sustituir, y ese desfase hay que licenciarlo
Podemos ayudarle a mitigar el incremento de licencias de su instalación y a mantenerse en línea con su ELA aunque no piense en deshacerse por completo de su proveedor de base de datos, se puede crear un entorno en el que se utilice la tecnología apropiada para cada carga de trabajo y así reducir el coste total de la plataforma.
Ejemplo de BBVA, sin nombrar.
Qué debemos hacer primero? Esta es una pregunta que nos hacen muy a menudo. La respuesta más simple y obvia es: Depende. Depende de los conocimientos de que disponga en su organización y depende de los planes y urgencia que tenga para ahorrar costes. Existen múltiples factores a tener en cuenta.
Nosotros hemos desarrollado una estrategia basada en nuestras experiencias con nuestros clientes, que hemos plasmado en la siguiente tabla. Verán las etapas a seguir en la adopción de Postgres junto con el beneficio de cada etapa. Por supuesto, en base a sus prioridades y conocimientos puede saltarse pasos, pero hemos prentendido condensar todas las posibilidades.
Si recuerda cómo comenzó el proceso de migración de Unix a Linux, recordará que comenzó con elementos de red perimetrales, como firewalls, balanceadore de carga, después paso a servidores de ficheros e impresoras, pasó a servidores web y por último acabó instalando servidores de bases de datos. Necesitó ir ganando confianza en las capacidades y posibilidades de Linux y en la capacidad de su equipo para administrar sus servidores. El mismo proceso aplica para las bases de datos, pero con una salvedad, las bases de datos almacenan los datos de su empresa.
Así que podemos decir que tenemos clientes que dan el salto a la piscina y clientes que siguen paso a paso el proceso descrito por la presente tabla.
Primero implantan nuevos servicios sobre la nueva base de datos, no realizan migraciones, despues pasan a replicar Postgres como base de datos réplica de Oracle, de tal manera que se libera a éste último de las cargas de trabajo más pesadas, manteniendo sobre Oracle la carga transaccioneal y llevando a Postgres las de business intelligence y generación de informes.
Por último se atacan migraciones de entornos no críticos y posteriormente, cuando se ha ganado la confianza necesaria y se dispone del conocimiento suficiente, migración de cargas de trabajo críticas, que son las que más recursos consumen.
Como la mayor parte de organizaciones, seguro que tiene categorizadas sus cargas de trabajo, algunas son consideradas de misión críticas y otras no.
Pues bien, Postgres está perfectamente indicado para cargas transaccionales, para aplicaciones web, almacenes de datos y como ya mencioné en la slide anterior, generación de informes. También es adecuado para data warehousing en determinados entornos no demasiado exigentes y estamos mejorando en nuestra relación con los fabricantes de aplicaciones para que soporten nuestra base de datos. Me gustaría también indicar que la situación ha cambiado espectacularmente desde hace unos años hasta la fecha, cuando antes era complicado encontar fabricantes de aplicaciones que soportaran Postgres, hoy día, es la regla, ocurre lo mismo que pasó con Linux, a principios de la pasada década el entorno de desarrollo por excelencia era Solaris y desde hace más de 10 años lo es Linux. Pues ahora estamos viviendo el mismo proceso…
Por ejemplo, la mayor parte de fabricantes de software de datawarehouses se basan en Postgres para construir sus herramientas, es el caso por ejemplo de Greenplum, Vertica, Netezza y Aster Data…
Aunque normalmente nosotros nos centramos en aplicaciones realizadas a medida en casa, nuestros clientes son principalmente entornos donde Java predomina y que ejecutan sus aplicaciones sobre Linux o Windows, pero Postgres también es muy popular entre desarrolladores de perl, php o Ruby.
COTS: Commercial off the Shelf application that does not have a Postgres version
OLTP: On line transaction processing system; System that captures daily business transactions; Active state, not historical
ODS: Integrated Database of data that supports analytical operational systems; Current Valued, Active State, not historical
DWH: Enterprise Data used to support business analysis and trending; frequently denormalized using cube-based or star-based data models; contains aggregates
Data Mart: Data used by a Department or Workgroup to support business analysis and trending
Archiving: Non-Integrated Data infrequently accessed that is retained for a long time
Reporting: Copy of OLTP or ODS used for reporting. Usually does not denormalize or aggregate data
Why DWH and ODS are the ‘analysis required’ category: DWH and Datamarts often rely heavily on cubes and stars. Postgres does not support these analytical functions today.
Why Enterprise/Mission critical is in the ‘analysis required’ category: certain uptime requirements and write scalability requirements are difficult to achieve with Postgres.
Y de hecho, tal y como se puede apreciar en este estudio realizado sobre nuestros clientes, utilizan postgres para una gran variedad de cargas de trabajo. Debe llamar la atención la evolución que ha tenido la respuesta de Mission Critical Applications, puedo asegurar he asistido a una rápida progresión de este número desde que llevo trabajando alrededor de esta tecnología.
Me gustaría sugerir que lo que ha realmente potenciado el uso de Postgres en entornos serios ha sido la aparición de un fabricante que ha generado una propuesta empresarial apoyada en un proyecto Open Source. Por qué es esto tan importante? Porque aquí, en EDB tenemos muchos miembros de la comunidad trabajando para la compañía y tenemos miles de clientes en entornos empresariales, así que con nuestra base de datos Postgres Plus Advanced Server ayudamos a conseguir configurar el círculo vicioso del que hablábamos al principio de la presentación:
Empezamos con el PostgreSQL comunitario que es construido por la comunidad de desarrolladores que decide que funcionalidades desean incorporar al proyecto.
Después EDB añade funcionalidades empresariales basadas en las necesidades de nuestros clientes, como por ejemplo la compatibilidad con Oracle.
Finalmente añadimos instaladores, realizamos pruebas y otros elementos que configuran el producto final, que es muy fácil de instalar y explotar.
Pero ésto no es el final de la historia. Como decíamos, EDB es un buen ciudadano de la comunidad de desarrolladores y revierte muchas características que la comunidad encuentra interesantes, a parte de por supuesto pagar el sueldo de contribuyentes netos a la comunidad que sólo realizan esa tarea.
Y debido a esta relación con el proyecto Open Source, el coste de generar nuestros productos, aunque no es despreciable, es significativamente más bajo que para fabricantes de bases de datos propietarias, y por supuesto, transferimos esos ahorros a nuestros clientes.
En esta slide pueden ver un ejemplo de un proyecto real, llevado a cabo por uno de nuestros socios más importantes, HP y su firma de consultoría externa.
Tengan en cuenta que el coste de EDB ya incluye los servicios necesarios para migrar las aplicaciones desde Oracle a Postgres Plus Advanced Server.
Estos beneficios pueden ser agrupados en función del impacto sobre el negocio en las siguientes categorías:
1.- $1,4M en reducción de coste en IT en tres años
2.- $135,000 en mejora de la eficiencia operativa en tres años.
3.- $142,000 en beneficios estratégicos.
Comparando el coste y beneficio del proyecto utilizando un análisis de flujo de caja descontado y factoring con una tasa de descuento ajustada al riesgo del 9,5%, el caso de negocio predice:
Retorno de la inversión del 271%
Ahorros actuales del $955,405
Tasa interna de retorno del 101%
Amortización del proyecto en 12 meses
Y en este proceso de adopción nunca estará solo, disponemos de los recursos necesarios, como soporte técnico, formación, preventa y consultoría que le ayudarán a determinar cuáles son los casos de uso más adecuados para comenzar esta andadura, y después le ayudaremos a obtener la configuración óptima en cuanto a seguridad, disponibilidad y rendimiento.
Uno de nuestros servicios más interesantes es nuestro OMA (Oracle Migration Assessment). Hemos diseñado un proceso simple y fácil para determinar qué aplicaciones son las mejores candidatas para migrar desde Oracle a EDB.
Lo llamativo es que en realidad, gracias a nuestra capa de compatibilidad con Oracle, la mitad de nuestros clientes no han tenido que hacer ninguna modificación en su base de datos, o si la ha habido, ésta ha sido mínima. Por lo general venimos haciendo migraciones con tiempos que van entre una semana o varios meses, dependiendo del volumen y la complejidad.
Lo interesante es que nunca nos embarcamos en una migración sin conocer su viabilidad y complejidad de antemano, con lo que tenemos garantía de éxito una vez se inicia el proyecto.
A la vista de los datos, cualquier puede admitir que los datos sobre ahorros son ciertos, pero también nos solemos enfrentar con una pregunta recurrente: en qué grado se reaprovechan los conocimientos de los administradores y programadores. La respuesta es que en el mismo grado que aquellos que migraron de Unix a Linux, como ejemplo puedo decir que tenemos un cliente en banca con centenares de bases de datos en producción cuyo personal nunca acudió a un curso de formación. El propio proceso de evaluación y adopción aportó el conocimiento y la experiencia necesaria para gestionar sus sistemas basados en postgres. Nada que ver si se enfrentaran a tecnologías no compatibles con Oracle, donde el coste podría ser interesante, pero el riesgo de fracaso pudiera ser mucho mayor.
Ahora dediquemos unos minutos a ver las diferencias entre el Postgres comunitario y nuestro PPAS
Tal y como mencionábamos, EDB parte como núcleo de su producto, del Postgresql comunitario, versión a versión y añade funcionalidades y capacidades necesarias en entornos empresariales.
Y las mejoras se agrupan en cuatro áreas fundamentalmente: Herramientas de géstión, Seguridad, Rendimiento, y la capacidad más diferencial: la compatibilidad con Oracle.
En cuanto a las mejoras en cuanto a seguridad se pueden destacar fundamentalmente dos: el firewal a nivel de base de datos, capaz de prevenir ataques por SQL injection, y la posibilidad de ofuscar el código almacenado en la base de datos, muy útil para desarrolladores.
En cuanto al rendimiento, tenemos dos tipos de mejoras, aquellas que afectan al propio gestor de bases de datos, como por ejemplo la capacidad para gestionar partiones con el mismo rendimiento que Oracle y las herramientas que permiten mejorar el diseño de la base de datos y mejorar sus tiempos de respuesta. Para nadie es un secreto que dependiendo como se escriba una consulta, el rendimiento puede variar dramáticamente. Esta capacidad es muy importante sobre todo cuando se viene de una migración y el cliente tiene unas expectativas de rendimiento.
Por otro lado con la versión empresarial proporcionamos un paraguas que engloba herramientas que permiten gestionar, monitorizar, optimizar replicar y migrar las bases de datos Postgres. Este paraguas se llama PEM (Postgres Enterprise Manager)
Así que aquellos clientes interesados en mejorar la seguridad, el rendimiento o la gestionabilidad de sus bases de datos, debe dirigirse a PEM.
I described the fact that we add Oracle compatibilty technology to the database to make it easy to migrate Oracle databases to PPAS. We have included PL SQL Syntax plus most of the stored procedures a developer would take advantage of when developing an application to Oracle. As you’ve seen, this accelerates the migration process and makes it safer and more cost effective.
We add features to the community postgres database in three other categories: security, tools, and performance, too.
We ensure that the strong foundation built by the community has the enterprise-class features companies expect when deploying databases in their production environment.
What’s more, we do this at a cost that’s 80-90% less expensive than Oracle.
PEM WITH EASY MANAGEMENT MONITORING AND TUNING ABILITY
So, for customers interested in enhanced security, peformance and tools…PPAS is their Postgres database of choice
Hemos, por supuesto dedicado nuestra atención a la percepción que se tiene de EDB en el mercado y hemos descubierto que somos la única base de datos relacional considerada en el cuadrante de “challengers”, es decir, con capacidad de entrega suficiente a nivel global y una visión adecuada para suponer un riesgo para los otros cuatro grandes jugadores que todos conocemos. Como podemos ver estamos muy cerca de estar en la parte baja del cuadrante de leaders…
En definitiva, proporcionamos a nuestros clientes las ventajas de un proyecto Open Source que continuamente innova tecnológicamente y por otro lado, los beneficios de contar con una empresa global que garantiza un soporte en 24 x 7 y demás servicios que se pueden esperar de un fabricante.